AI agent boundary enforcement belongs outside the model

At a glance

What this is: This is an analysis of LLM-agent isolation research, and its key finding is that agent safety depends on hard boundaries enforced outside the model, not on prompt instructions or refusal behavior.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent-tool, agent-execution, and agent-agent boundaries as identity enforcement problems, not just AI safety concerns.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Pomerium's analysis of agent boundary enforcement and MCP access control

Context

LLM-agent security fails when teams assume the model can be trusted to keep its own boundaries. The article's central argument is that prompt instructions are soft controls, while policy engines, scoped credentials, and egress restrictions are hard controls that must sit outside the model. For AI agent identity governance, that means the access layer becomes the control plane.

The same pattern shows up in NHI programmes that already struggle with service account sprawl, over-privilege, and weak visibility. Once an agent can choose tools, shape execution, or communicate with other agents, identity risk stops looking like a static authentication problem and starts looking like runtime authority management.

This is typical of the current market moment: organisations are adopting agentic workflows faster than they are building enforcement around them. The result is a familiar zero trust lesson applied to a new actor type, where containment matters more than persuasion.

Key questions

Q: How should security teams set access boundaries for AI agents?

A: Security teams should define agent boundaries around data sources, tools, and allowed actions before any production rollout. The boundary must be explicit enough to block unintended combinations of access, because agent value often comes from chaining capabilities across systems. Treat the boundary as a runtime control, not just a policy document.

Q: Why do autonomous AI systems change the way IAM teams think about least privilege?

A: Least privilege becomes harder to define when intent is not fixed at provisioning time. An autonomous system may choose different tools and sequence them differently in each session, so the minimum necessary access is not a static list. IAM teams must evaluate what the actor can do at runtime, not only what it was granted on paper.

Q: What breaks when agent execution is allowed to inherit model trust?

A: The separation between reasoning and authority collapses. A model that is only meant to decide can end up with the credentials to act, which means one compromised prompt can become a real change in systems, data, or workflows. Execution must be governed as a distinct control point.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Agent-tool boundaries and least privilege for AI agents

The agent-tool boundary is where an agent selects an external capability, passes arguments, and consumes tool output. This is not just API integration, because the tool catalogue and metadata can shape the agent's routing before any action occurs. In MCP-style environments, the model may see descriptions that bias selection, but the real control point is whether the request can be constrained by identity, scope, and policy before execution. Least privilege for agents therefore means explicit capability scope, not implied trust in the model's reasoning.

Practical implication: scope each agent to named tools, narrow argument patterns, and deny-by-default policy at the gateway.

Agent-execution boundaries and governed action

Agent-execution is the transition from model output to a real-world action such as clicking, submitting, changing configuration, or invoking an API with impact. Once execution begins, refusal tuning is no longer the right control because the model is no longer only producing text. The article's core architectural point is that execution must be treated as a governed interface, with short-lived credentials, explicit authorization, and logging outside the model. This is where identity and access controls become the safety mechanism.

Practical implication: separate decision-making from action credentials so the model never directly carries durable authority.

Agent-agent trust and recursive delegation

Agent-agent boundaries matter when one agent can message, trigger, or delegate to another. The risk is not merely information sharing, but control propagation, because a message can become a command channel. If sub-agents inherit trust by default, compromise amplifies across the delegation chain. Identity-aware enforcement should require each agent to authenticate as a distinct principal and each cross-agent request to pass through the same authorization layer. That turns collaboration into a controlled exchange rather than an implicit trust network.

Practical implication: give every agent and sub-agent distinct identity, separate approval scope, and auditable cross-agent policy checks.

NHI Mgmt Group analysis

Hard boundaries, not prompt discipline, are the only durable control model for agents. The article correctly identifies that refusal behavior, model training, and system prompts remain probabilistic under pressure. That means the security boundary must live in identity-aware infrastructure, where policy is deterministic and independent of model persuasion. The practitioner conclusion is that agents should be governed like any other privileged runtime, only with tighter execution controls.

Agent-tool scope is a new identity problem, not just a software integration problem. The paper's five-boundary model makes clear that the first exploitable seam is often the point where tool selection becomes action. That is where least privilege, scoped tokens, and explicit trust levels matter most. The practitioner conclusion is to treat tool access as a route policy and not as an application feature.

Boundary failures rhyme because they all share the same broken premise: control can be left inside the model. That premise was designed for systems where generated text could not directly become authority. It fails when the actor can choose tools, shape timing, and produce real effects without a human approval gate. The implication is not merely more monitoring, but a redesign of where authority lives.

Agent-execution belongs in the governance stack, not in the model prompt. The article's strongest contribution is to separate thinking from acting and to insist that the second step is externally enforced. That aligns with zero trust principles across NHI and human identity: the entity that decides should not automatically be the entity that executes. The practitioner conclusion is to hard-separate decision, identity, and action.

Cross-agent communication needs the same discipline as privileged east-west traffic. The paper's message that a message can carry control is a reminder that agent-to-agent links are not benign metadata flows. They are delegated authority paths with their own blast radius. The practitioner conclusion is to govern sub-agents as distinct identities with per-request enforcement, not as informal extensions of the parent agent.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• That aligns with our Ultimate Guide to NHIs, which shows only 5.7% of organisations have full visibility into service accounts, making hidden machine access a structural risk.

What this signals

With only 5.7% of organisations having full visibility into service accounts, the extension of agentic systems into infrastructure is not a niche AI problem, it is an identity blind spot that existing programmes already struggle to close. Teams should expect boundary enforcement to move from application design into access governance, routing, and privileged workflow control.

Runtime boundary governance: the next maturity step is not better prompt writing, but deterministic enforcement around where agents can call, what they can pass, and when they can execute. That means mapping agent paths to identity policy, then measuring whether every action is reviewable, revocable, and attributable before the session ends.

For practitioners

• Move boundary enforcement outside the model Place policy evaluation, credential issuance, and egress control in infrastructure that the agent cannot rewrite or persuade. Treat the model as an untrusted decision source and the proxy or gateway as the enforcement point.
• Scope agent tool access by capability Restrict each agent to a minimal set of named tools and accepted argument patterns. Deny unexpected tools and malformed action requests at the enforcement layer before the request reaches the backend.
• Separate execution credentials from reasoning Issue short-lived, request-scoped tokens for agent actions and ensure the reasoning component never holds durable secrets. This prevents a compromised model from turning a single bad output into persistent authority.
• Authenticate every sub-agent as a distinct principal Require per-agent identity and per-request authorization for any cross-agent communication. Do not let a delegated agent inherit trust simply because it was spawned by a trusted parent.

Key takeaways

• AI agent safety collapses when teams rely on prompt instructions instead of structural enforcement.
• The same boundary failures recur across tool use, execution, and agent-to-agent delegation because the control layer is in the wrong place.
• Identity teams should treat agents as governed principals with scoped authority, not as chat interfaces with extra permissions.

Key terms

• Agent-tool boundary: The point where an AI agent selects and invokes an external tool or capability. In practice, this is where identity, policy, and request scoping have to override model preference, because unsafe tool choice can turn a linguistic prompt into an operational action.
• Agent-execution boundary: The transition from model output to a real-world effect, such as a configuration change, API call, or workflow submission. For agents, this boundary matters because a model that decides is not automatically entitled to act, and execution must be separately authorized and logged.
• Agent Boundary: The point where external content, tool outputs, and environment data enter an agent's decision-making path. This is where validation, filtering, and authorization need to happen, because anything admitted at the boundary can shape the agent's next action and expand the attack surface.

What's in the full article

Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact route-policy pattern used to constrain MCP tool access in front of internal applications.
• How short-lived identity issuance changes the execution boundary for agents that can click, submit, or call APIs.
• The logging and audit context attached to allow-or-deny decisions at the proxy layer.
• The separation between user-agent, system-environment, and agent-execution controls in the five-boundary model.

👉 Pomerium's full post explains the five-boundary model, policy examples, and logging approach in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.