An autonomous agent will do exactly what its tools let it do, and no more. This sounds like a constraint. In practice it is the whole risk, because the set of things an agent’s tools let it do is almost never the set anyone deliberately chose. It is the set that accumulated. A tool added for one workflow stays available for every workflow. A credential scoped for a demo survives into production. A delegation added to unblock a Friday deploy becomes a permanent edge in the graph. Nobody decides to give the agent that reach. There was never a moment where reach was decided at all.

This is the pattern worth naming. It is not a bug in any particular agent framework and it will not be fixed by a better prompt. Across enough deployments the same shape recurs: authority is granted incrementally, locally, and invisibly, and the system’s actual power drifts steadily away from anyone’s model of what it should be able to do. The agents behave. The boundaries erode anyway. By the time someone asks “wait, can it do that?”, the honest answer is usually “it could for weeks, and we only noticed now.”

The instinct is to treat this as a governance failure and answer with process and review boards. That instinct aims at the wrong layer. Process governs the decisions humans make. This problem is largely about the decisions nobody makes, the capabilities that arrive without a decision, and you cannot review a class of change that never surfaces as a change. What is needed is not more vigilance over the agent. It is a substrate that holds the line whether or not anyone is watching.

Why the agent cannot hold its own boundary

The tempting shortcut is to make the agent responsible for its own limits: tell it in its instructions what it may and may not do, and give it a sense of its own scope. This fails structurally, and the failure looks like success right up until it doesn’t.

An agent’s output is a probability distribution over next actions, conditioned on context. It is not a guarantee. Most of the time the most probable action is the appropriate one, which is exactly what makes agents useful and exactly what makes them dangerous to trust. A boundary that holds ninety-nine times and yields on the hundredth is not a boundary; it is a strong suggestion with a failure rate. And the conditions that push an agent toward the edge of its instructions, novel inputs, adversarial phrasing, unusual state, are precisely the conditions where the boundary matters most and where probabilistic adherence is weakest. You rely on the mechanism least when you need it most.

Underneath the reliability problem sits a harder one. Even a perfectly compliant agent, one that always did exactly what its instructions said, would still have whatever authority its tools and credentials actually grant. The instruction is a statement of intent. The tool binding is a statement of capability. When those two disagree, capability wins, because capability is what executes. An agent instructed not to move money, but holding a tool that moves money, is one clever prompt or one confused reasoning step away from moving money. The gap between intended scope and granted capability is the entire attack surface, and no amount of instruction closes it, because instruction and capability live in different layers and only one of them runs.

So the boundary has to live where capability lives. Not in the agent’s reasoning, but in the infrastructure that decides what the agent’s reasoning is able to reach. Bounded autonomy is not a property of the agent. It is a property of the platform the agent runs on.

The safe operating model

Once the boundary belongs to the platform, the problem stops being novel. The industry has spent fifteen years learning to bound what a workload can do, because a microservice is also software that will do whatever its identity, network access, and permissions allow. We built a discipline around not trusting a workload to police itself. An agent is a workload. It is an unusually capable workload with a non-deterministic control loop, but the machinery that bounds workloads applies to it directly.

The Safe Operating Model organizes that machinery as concentric rings of least privilege. Each ring binds one question about the agent, and each outer ring depends on the one inside it. The order is not decorative. Reach cannot be enforced without knowing what is connecting; capability cannot be enforced without knowing what is acting. Identity is the center because every other control resolves against it.

The core: Identity

Identity comes first because every other control depends on knowing what is acting. A workload identity standard issues each agent and each tool server a short-lived, attested credential. The platform no longer takes an agent’s word for what it is; it verifies. Every downstream decision, every reach check, every capability check, keys off this verified identity rather than a bearer token that can leak or be replayed. Get this wrong and the rest is built on sand. Get it right and the boundary has something real to attach to. Everything outward from here is an elaboration of a single question the core has already answered: what, exactly, is this.

Ring 1: Reach

With identity established, the first thing to bound is reach, meaning what the agent is permitted to connect to. A service mesh enforces this on the verified identity, per connection, independent of network topology. The agent may talk to the specific peers its work requires and to nothing else, and nothing else is the default rather than an afterthought. When an agent tries to reach a service it has no declared relationship with, the connection is refused before it opens.

This is where the drift problem first meets a wall. A new edge in the agent’s reach cannot appear quietly at runtime, because reach is declared, and a change to a declaration is visible, reviewable, and attributable. The graph cannot grow in the dark. The accumulation that defined the original problem, one more connection, one more integration, no single one of them a decision, becomes a series of changes that each have to be made on purpose.

Ring 2: Capability

Reach controls who the agent can talk to. Capability controls what it can actually do, and this is where an agent’s autonomy cashes out: which tools it may invoke, and what it may do to the system. Two enforcement points matter, and they answer two different questions.

The first is admission, which governs what capabilities the agent is allowed to hold. When the object that defines an agent’s permitted tools is a declarative resource in the cluster, policy can reject any attempt to bind a tool that was never approved, at the moment of the attempt, before the binding exists. An agent cannot acquire a capability that policy has not sanctioned, because the acquisition itself is what gets denied. A tool nobody reviewed cannot enter the system through the back door of an agent quietly adding it.

The second is the call path, which governs what the agent may do with the capabilities it holds. Even among sanctioned tools, a gateway can authorize each individual invocation against the agent’s identity, so that a tool being present and reachable is not the same as a tool being callable. Ask for a tool outside the permitted set and the answer is a refusal, and the tool does not even appear in what the agent can see. Capability becomes something granted per action rather than something latent and waiting to be misused. Holding a tool and being allowed to use it, in a given moment, for a given task, are separated on purpose.

The keystone

One control sits above the rings and makes them coherent, and it is the one most easily forgotten. Every boundary described so far is expressed as configuration. Identity registrations, mesh authorizations, admission policies, tool allow-lists, all of it is declarative state. Which raises the obvious question: what stops the agent from changing that state? An agent that can edit its own capability definition, or relax the policy that binds it, or grant itself a role, has no real boundary at all, only a boundary it is permitted to remove.

So the load-bearing rule, the one that makes bounded autonomy actually bounded, is that the agent’s own identity is denied any ability to modify the objects that define its authority. It can act within its bounds. It cannot rewrite them. Changing what an agent is allowed to do is reserved for a reviewed change to version-controlled configuration, made by a human or a pipeline, never by the agent at runtime. This is what converts a set of controls into a boundary the agent cannot dissolve from the inside, and it is why the model is a set of rings rather than a checklist. The keystone holds the rings closed.

Ring 3: Data

The outermost ring bounds which records the agent may see, and it is worth being honest about where it lives. Data scope is enforced at the data plane, by the systems that hold the data, rather than by the mesh or the admission controller. But it is not separate from the model, because the enforcement point authorizes against the same verified identity the core established. The rings make data governance possible even though they do not implement it: the identity that proves what the agent is becomes the key the data layer checks. Reach and capability keep the agent away from data sources it should never touch; the data plane decides, within the sources it may touch, which rows are its business.

The deterministic spine

None of this argues against agent autonomy. It argues about where autonomy belongs. The useful frame is a deterministic spine with non-deterministic execution hanging off it. The spine is the part of the system that must be repeatable, auditable, and correct: the workflow that owns the regulated process, the state, the approvals, the record of who did what and when. That belongs to deterministic infrastructure, durable workflow engines and version-controlled policy, the kind of software that fails the same way every time and leaves a trail. The agent lives inside that spine, in the places where judgment is genuinely valuable: interpreting a document, weighing a signal, drafting a recommendation. It does real cognitive work. It does not own the outcome.

In a regulated workflow this is not stylistic. Consider loan origination. The agent can read the application, pull the relevant signals, weigh the risk, and produce a recommendation with its reasoning attached. What it must not do is approve the loan, price it outside policy, or move the funds. Those are deterministic gates and human decisions, and the platform is what keeps them deterministic. The most robust expression of this has the agent emit a proposed change, a draft, a recommendation, a pull request against desired state, which a human reviews and a pipeline applies. Approval stops being a step the agent can talk its way past and becomes a property of the system: the agent has no path to the outcome except through a gate it does not control.

This is also what makes the arrangement auditable in the way regulation actually requires. When identity is verified, reach is declared, capability is granted per action, and outcomes flow through reviewed changes, the system produces evidence as a byproduct of operating. You do not reconstruct what the agent was allowed to do; the platform recorded it. You do not trust an after-the-fact account; the boundary left a trail. Provenance that falls out of enforcement is worth more than any assurance an agent could give about its own conduct.

What this asks us to build

The argument leads somewhere concrete, and it is the opposite of building agent-specific security from scratch. The mature cloud native stack already contains what the Safe Operating Model needs, and the work ahead is integration and rigor rather than invention. Workload identity for agents. Mesh-enforced reach on that identity. Policy-as-code at admission for capability. Per-call authorization at the tool boundary. Version-controlled configuration as the only path to changing any of it. And the discipline to keep the agent out of its own guardrails. These are engineering commitments, and every one of them has a production-grade project behind it today.

What is genuinely new is small and specific: expressing an agent’s identity and its permitted capabilities as first-class declarative objects, and enforcing the per-tool authorization that agent-to-tool protocols introduced. That surface is young and moving quickly. But it is a thin new layer on a deep and stable foundation, not a green field. The people who will build trustworthy agentic systems are not the ones searching for a new security paradigm. They are the ones who recognize that an agent is a workload, that workloads have always needed bounding, and that the platform is where bounding has always belonged.

The boundary will not come from the agent. It was never going to. Agents are built to explore the space of possible actions, which is exactly why something other than the agent has to decide the shape of that space. Draw the boundary in the platform, make it the default, and let the rings hold it. That is not a limitation on what agentic AI can become. It is the precondition for letting it become anything we can safely rely on.

At KubeCon + CloudNativeCon North America 2026 in Salt Lake City, William Rizzo and Kasper Nissen will take these principles from architecture to implementation, exploring how cloud native technologies and projects can be combined to deliver the platform capabilities required to securely govern, observe and operate agentic systems in regulated enterprises. “Verticalizing Platform Intelligence for Regulated Domains.”