Why the Runtime Is the Control Plane for Agentic AI

Every enterprise AI architecture review ends up at the same question: when an agent takes an action, who can vouch for it?

Most answers start with a gateway. Put a proxy in front of your tools, inspect the traffic, write some policy, and call it governance. It’s starting down the right path, but a gateway alone does not go far enough.

Identity is not something you can inspect into existence after the fact. It is decided at the moment an agent starts, by whatever starts it. That thing is the runtime. If you don’t own the runtime, you don’t own the identity, and if you don’t own the identity, you are guessing at everything downstream of it.

This is why Stacklok started with our open source projects, ToolHive as the runtime for the tools an agent calls, and Mecatl as the runtime for the agent itself. This core is pushed further in Stacklok’s Enterprise platform. This approach to runtimes ensures that a platform team can answer the question above with a verifiable chain rather than a best guess, whether the agent is running in their own cluster or somewhere outside their firewall.

Why a gateway can’t answer the question

A gateway sees a request only after it has been made. It has to infer who sent it from whatever token or header happens to be on the wire. If the agent was launched with a shared service account, a borrowed API key, or no identity at all, the gateway can only report that something called the tool. It cannot say which agent, acting for which person, under which authorization.

The identity question was settled earlier, at launch time, and the gateway wasn’t there for it. It is a security guard at one door checking badges. If nobody issued real badges, the guard is just guessing.

Agent frameworks have the mirror-image problem. Most desktop harnesses bundle the user interface, the agent loop, the filesystem, the tools, the credentials, and the conversation state onto one long-lived machine. The agent has access to everything on that machine, inherits whatever credentials happen to be sitting on it, and leaves no first-party record of what it did with them. Putting that machine in a container changes where it runs, not how it is built.

So the industry’s two default answers each cover half the problem. The gateway can check a badge but can’t issue one. The framework can run an agent but can’t bind it to an identity the rest of the enterprise can verify. Neither owns the launch.

The runtime thesis: own the launch, own the identity, own the audit

The runtime is the thing that actually starts an agent or a tool. Because it is present at that moment, it can do three things nothing else in the stack can.

1. Issue identity at birth. The runtime can hand each agent its own uniquely issued, scoped credential, not a copy of the user’s credentials or a shared service account. Every action the agent takes afterward carries that identity, because the runtime is the one mediating the action.
2. Draw the boundary. The runtime decides what the agent can reach: which network, which filesystem, which secrets, which tools. A container, a sandbox, and a policy engine all live here. Anything outside that boundary is not merely blocked at a door; it was never in the room.
3. Write the record. The audit trail comes from the same component that enforced the policy. It is a first-party account of what happened, not a reconstruction stitched together from logs that never saw the full picture.

If the gateway is the security guard, the runtime is the HR system that issues the badge, decides which doors it opens, and can cancel it instantly. You can have guards without HR, but then every badge is forged or borrowed.

Kubernetes made the same argument for workloads a decade ago: control the scheduler and the pod boundary, and you control identity, policy, and observability for everything that runs. It is not a coincidence that Stacklok’s founders are applying what they learned from Kubernetes to AI architecture.

ToolHive: the runtime for tools

ToolHive is the runtime for MCP servers, the connectors that let an agent reach the systems it needs to do real work. Every MCP server is third-party code running inside your environment with access to your agent’s context and credentials.

ToolHive runs every MCP server in an isolated container, locally through Docker or Podman or in a cluster through the Kubernetes operator, with permissions, network filtering, and secrets management applied on the way in. When connected to an identity provider, it verifies identity and enforces access policy on every request, down to individual tools, resources, and prompts. OpenTelemetry traces and Prometheus metrics come out of the same path that enforced the policy.

The launch-time control is what makes the rest possible. Because ToolHive starts the server, it can bind the request path to your IdP rather than to whatever credential the agent happened to bring. With Enterprise-Managed Authorization, built on the emerging IETF ID-JAG standard, every tool call carries the identity of the real person who started the work. When that person’s access is revoked in the IdP, their agents lose it on the very next action. There is no shared password or standing credential for a breach to expose.

ToolHive is open source under Apache 2.0, with external maintainers, an active community, and more than 20 million tool calls secured each month. The Kubernetes operator is in production at multiple Global 2000 firms. Stacklok Enterprise builds on it with a curated registry, fleet-scale authorization compiled from declarative policy, and Okta and Entra ID integration.

Mecatl: the runtime for the agent

ToolHive settles identity for the tools. But the agent calling those tools is usually a desktop harness that ToolHive meets only at the door.

Mecatl closes that gap. It is an open source, cloud-native harness: an agent runtime whose clients, execution environments, and durable state are managed as separate services. The core engine owns the agent loop. Everything else sits outside it behind explicit boundaries, so the same loop can run on a laptop, as a service, or across a fleet of Kubernetes pods without being replaced.

That decomposition is what lets Mecatl be the identity anchor for the agent, not just a host for it.

• Identity at every action. Every agent acts under a verifiable identity, stamped on each action rather than once at a login gate.
• Control separated from execution. The loop and the sandbox are different services, so untrusted code runs outside the trust boundary that holds the agent’s credentials.
• Durable, first-party record. Workers are disposable; sessions and the event history are not. OpenTelemetry traces come from the component that enforced permissions.
• A governed tool catalog. Purpose-built tools, MCP services, and skills are exposed through an explicit catalog, each governed by permissions, audit records, and execution-environment boundaries. ToolHive-managed MCP servers slot in directly.

Where Mecatl is heading matters as much as what it does today. Our stated intention is that external systems receive a verifiable delegation chain showing which user, agent, and subagent acted with which authority, with Mecatl as its own SPIFFE trust domain encoding that chain in JWTs. That is the piece that lets a system outside your network verify who is acting without having to trust your network.

Better together: one chain from the person to the tool

With both runtimes in place, Stacklok is the only party in the chain that issued identity to both the actor and the thing it acted on.

The person signs in through the identity provider they already run. Mecatl starts the agent under its own scoped identity and stamps that identity on every action, including the ones its subagents take. When the agent calls a tool, ToolHive starts the MCP server in isolation and checks the request against the same IdP. The record of what happened is written by the components that enforced it, end to end.

That chain is what makes “trace an agent anywhere” a real claim rather than a slogan. Inside the customer’s own infrastructure, the Kubernetes operators for both projects give the platform team the launch, the policy, and the logs. Outside the firewall, on a developer laptop, in a vendor’s cloud, or in a SaaS environment, the identity still travels with the agent, because the runtime that produced it is federated back to the customer’s IdP rather than depending on network control of wherever the agent happens to be running.

A vendor with only a gateway can tell the tool half of this story. A vendor with only an agent framework can tell the agent half. Telling the whole story requires owning both launch moments.

What this means for platform and security teams

The practical payoff is that the hard questions in an agent security review stop being open questions.

• Who is acting? A specific person, through a specific agent, with a specific scoped credential. Not a shared service account.
• What can it reach? Only what the runtime handed it: an isolated container for each tool, a sandbox separated from the loop that holds credentials, and a catalog of tools the platform team approved.
• Can we turn it off? Revoke the person in the IdP and their agents lose access on the next action. There is no separate agent access to track down.
• Can we prove it? The audit record is written by the components that enforced the policy, and the direction is toward a signed delegation chain that systems outside your network can verify on their own.

There is a second, quieter benefit. Both runtimes are open source and designed to compose with the identity provider, telemetry stack, and Kubernetes clusters you already run. That is the point of Stacklok’s commitment to an open alternative to vertically integrated agent stacks. A platform team should be able to pick a model provider, a client, a set of tools, and a cloud without any of those choices deciding who gets to govern the agent. The runtime is the one layer that has to be yours.

Get started

Both runtimes are open source and run on a laptop in minutes.

• ToolHive: run any MCP server in an isolated container, then deploy the Kubernetes operator when you’re ready for a fleet.
• Mecatl: start with mecatui locally, then deploy mecak8s to run agents as stateless pods with durable sessions.
• Stacklok Enterprise: the curated registry, fleet-scale authorization, and Okta and Entra ID integration that put both runtimes to work across an organization.

If your architecture review keeps landing on the same question, we’d like to show you how it gets answered. Join us on Discord or reach out to the team.