AI agent boundary enforcement belongs outside the model

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pomerium's blog post: Five agent isolation boundaries show that AI agent safety fails when enforcement lives in the model instead of the infrastructure.

Why it matters: IAM and security teams need this because agent-tool and agent-execution paths turn identity and authorization into runtime control points, not prompt-quality problems.

Context

The central problem is boundary failure, not weak prompting. When an AI agent can read text, call tools, and submit actions, security breaks at the point where perception becomes control unless enforcement sits outside the model.

For identity programmes, that means agent governance has to be treated as an authorization and containment problem across tools, execution, and peer-to-peer communication. Zero trust logic applies here because the system must assume the model can be persuaded while the infrastructure still needs to decide what is allowed.

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 prompt filters fail to stop risky agent behaviour?

A: Prompt filters only inspect text, but risky agent behaviour appears when that text becomes an API call, shell command, or other executable action. If policy is applied only to the message, the system can still complete the harmful step downstream. The control failure is at the action layer, not the language layer.

Q: What breaks when an AI agent is allowed to call tools without strict scope controls?

A: The main failure is privilege expansion. A model can only act safely if every tool it can call is constrained by explicit scope, server-side validation, and audit logging. Without those controls, the agent can read files, trigger actions, or expose data far beyond what the user intended, turning a helpful assistant into an uncontrolled access path.

Q: How should teams govern cross-session delegation between AI agents?

A: Treat session-to-session messaging as a delegated access path and require explicit ownership, scope, and approval rules before one agent can act on another’s blocked or denied request. Without that boundary, an agent can launder authority across sessions even when no single user intended the outcome. The governance problem is delegation, not only execution.

Technical breakdown

Why soft guardrails fail at agent boundaries

Model prompts, refusal training, and alignment tuning are probabilistic controls. They shape behaviour, but they do not reliably prevent a model from turning adversarial text into action once the agent can select tools or submit requests. The article’s core technical point is that the real security boundary is not the model output itself, but the interface where that output becomes a request against a system you control. That is why prompt injection, tool misuse, and execution abuse keep appearing together. Practical implication: treat the model as untrusted decision support and enforce policy at the control points that receive its requests.

Practical implication: move enforcement to the gateway, policy engine, or service boundary that evaluates the action before it reaches the target system.

What the five isolation boundaries actually protect

The survey groups failures into user-agent, agent-tool, agent-execution, agent-agent, and system-environment boundaries. User-agent failures cover prompt injection and memory poisoning, while agent-tool failures include unsafe tool choice, unsafe arguments, and misleading tool metadata. Agent-execution is where a model’s internal decision becomes an operational side effect, and agent-agent is where one message can carry control rather than information. System-environment covers webpages and retrieved content that should remain observations, not hidden instructions. Practical implication: each boundary demands a different control layer, so one generic AI safety control will not cover the whole attack surface.

Practical implication: map each boundary to a distinct defensive control rather than assuming one content filter or refusal policy is enough.

Why access-layer enforcement is the decisive control point

The strongest part of the article is its claim that agent-tool, agent-execution, and agent-agent violations all cross the network and can therefore be intercepted by infrastructure. That is where identity-aware gateways, scoped credentials, short-lived tokens, and request-level authorization matter. The model may still be persuadable, but it no longer holds unconditional ability to act. This is the same structural logic as zero trust: trust is not inferred from intent, and authority is not inherited from a prompt. Practical implication: put authorization ahead of execution so every agent request is checked as a governed transaction.

Practical implication: require per-request authorization and scoped credentials before any tool call, side effect, or downstream delegation occurs.

NHI Mgmt Group analysis

Isolation by construction is the right control model for AI agents. The article’s real contribution is not a new prompt defense, but the argument that security fails when the system trusts the model to remain bounded. Once a model can influence tools, execution, or peers, the only durable control is structural enforcement outside the model. That is the point practitioners should carry into zero trust and NHI governance.

Agent-tool boundaries expose an identity gap, not just an application gap. The moment an agent can choose or misuse a tool, authorization becomes a runtime transaction instead of a static permission check. Capability scope, trust level, and action semantics need to be explicit before the request reaches the target. Practitioners should treat tool access as governed NHI access, not as model behavior.

Agent-execution changes the meaning of least privilege. The model that reasons should not be the component that holds standing ability to act. If reasoning and execution remain coupled, a compromised instruction can become immediate operational impact. The practical conclusion is that access must be terminated, scoped, and re-evaluated at the boundary where action is taken.

Agent-agent communication creates a trust propagation problem. A message between agents is not merely data if it can steer another actor’s behaviour or delegation path. That means inter-agent channels require the same scrutiny as privileged access paths, because one compromised participant can amplify risk across the system. Practitioners should model agent-to-agent exchange as an authorization surface.

AI agent safety is becoming a governed identity discipline. The article reinforces a broader market truth: once agents can call tools and trigger actions, they behave like non-human identities with runtime authority. Existing IAM assumptions about stable intent, static privilege, and human-paced review no longer hold cleanly. Teams should redesign governance around request-time enforcement, not post-hoc review.

What this signals

Isolation by construction: agent governance is moving from model quality debates to boundary enforcement. The practical change for programmes is simple: if an agent can act, the decisive control is no longer the prompt, it is the request path that authorizes the act.

Identity teams should expect AI agents to be governed more like runtime non-human identities than like chat features. That pushes policy, token scope, and auditability into the access layer, where existing IAM and zero trust patterns can actually make a difference.

For practitioners

• Enforce policy outside the model Place an identity-aware gateway or policy engine in front of MCP servers, APIs, and internal apps so the agent’s request is evaluated before any side effect occurs.
• Scope every tool call explicitly Limit each agent to named tools, named destinations, and named actions so capability scope is visible and machine-enforced rather than inferred from prompt text.
• Terminate and reissue credentials per request Use short-lived, scoped tokens for each action path so the agent never carries standing authority across unrelated tasks or sessions.
• Authenticate every sub-agent separately Require distinct identities and authorization checks for spawned or peer agents so one compromised message cannot become a delegated control channel.
• Log allow and deny decisions with context Capture the full request, policy result, and target resource for each agent action so investigation can reconstruct how a boundary was crossed or held.

Key takeaways

• AI agent safety breaks down when boundaries are enforced by prompts instead of infrastructure, because the model can still be persuaded to attempt unsafe actions.
• The article’s five-boundary taxonomy explains why prompt injection, tool misuse, memory poisoning, and unsafe execution often show up together as one control problem.
• Practitioners should move authorization ahead of execution and treat agents as governed identities with scoped, logged, request-level access.

Key terms

• Isolation by construction: A control approach where boundaries are enforced structurally by infrastructure, policy, and scoped identity rather than by model instructions. In agentic systems, it means the system is designed so unsafe outputs cannot directly become privileged actions, even when the model is coerced or misled.
• 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-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-agent boundary: The communication layer between multiple AI agents or sub-agents. It becomes a security control point when messages can influence decisions or delegation, which means a message may function as control rather than information and needs identity and authorization checks.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.