AI agent security needs both content checks and access controls

At a glance

What this is: This analysis argues that AI agent security is split between content policy enforcement and access authorisation, and that delegation chains create a gap neither control closes alone.

Why it matters: IAM, PAM, and agentic AI teams need to separate content safety from delegated access scope, or they will miss the point where an agent should be denied tool or data access regardless of prompt safety.

Context

AI agent delegation changes the security problem from a single request to a chain of requests, where identity and scope can shift between hops. In practice, content filtering answers whether a prompt or response is safe, but it does not answer whether the agent making the request should be allowed to act on the target data or tool.

That distinction matters because A2A systems can preserve operational continuity while quietly stretching trust across multiple agents. For identity programmes, the governance question is no longer just what the content says. It is whether access, purpose, and delegation remain bound to the original actor through the full execution path.

Key questions

Q: What breaks when security teams rely on content guardrails to control AI agents?

A: Content guardrails only inspect what an agent says, not what it does. They fail when the real risk is action execution, because an agent can still use credentials, reach external systems, or probe infrastructure while producing harmless text. Security teams need runtime authorization and containment, not just prompt and output filtering.

Q: Why do delegated AI agent chains increase access risk?

A: Because each hop can lose the original task boundary. If identity and scope are not propagated across delegation, downstream agents may inherit access that no longer matches the initiating purpose. The result is scope drift, where the chain still looks legitimate in traces but is no longer governed by the same access decision.

Q: How do security teams know whether an AI agent control stack is actually working?

A: Look for three things: every agent has a traceable identity, permissions are narrow enough to explain in operational terms, and actions can be audited end to end. If any of those are missing, the control stack is incomplete even if the data layer uses advanced privacy techniques. Identity, scope, and logging should all line up.

Q: What should organisations do when an AI agent delegates work to other agents?

A: Organisations should require a traceable delegation chain that records the initiating identity, each handoff, each tool call, and the business purpose of downstream access. Without that chain, teams cannot determine whether the final action still matched the original authorization or whether privilege expanded silently as the workflow progressed.

Technical breakdown

Content guardrails stop unsafe text, not unsafe access

Inline guardrails evaluate the content moving through a request. They can block jailbreak prompts, toxic outputs, and direct leakage of secrets, PII, or PHI before those bytes leave the request path. That is useful, but it is still content inspection. It does not determine whether the requesting agent has a valid business purpose for the underlying data source or whether a tool call is authorised for the task at hand. In agent systems, the control plane must distinguish between what is being said and what is being done, because those are not the same security decision.

Practical implication: treat content policy as a filtering layer, not as an access decision for tools, datasets, or downstream actions.

Purpose-based access control governs delegated agent identity

Purpose-based access control evaluates whether an agent should reach a resource at all, based on the declared purpose of the request. That shifts the decision from message safety to access scope, and in agentic systems the scope must be short-lived and task-bound rather than standing. This is the identity problem underneath AI agent security: a request may be syntactically safe and still be operationally unauthorised. When the agent is allowed to delegate, the authorisation decision must travel with the task, not stay behind at the first hop.

Practical implication: bind access to declared purpose and task scope, not to a persistent agent identity that can be reused across requests.

A2A delegation breaks single-hop trace assumptions

Agent-to-agent delegation creates a chain where the original request may be handed off several times before data access occurs. Each hop can preserve enough context to continue execution while losing the clarity of who is authorised to do what. Tracing alone shows the chain after the fact, but authorisation must answer the question before each hop is allowed to extend scope. Without that, the system may still look observable while the effective trust boundary has already dissolved.

Practical implication: enforce authorisation at every hop in the delegation chain, not only at the first agent boundary.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Content safety and access authorisation are different controls, and confusing them creates a false sense of coverage. A prompt can be safe while the agent behind it is not entitled to the data or tool it is about to use. That is a governance distinction, not a tuning issue, and programmes that collapse it into one layer will overestimate their control coverage. The practitioner conclusion is that content checks and access checks must be designed as separate enforcement points.

Delegated identity is the real control boundary in A2A systems. Once an agent hands work to another agent, the security question becomes whether the original purpose, scope, and authority still hold. If the chain can expand without a fresh access decision, then identity has effectively become portable in a way most IAM models do not account for. The practitioner conclusion is that delegation must be treated as an authorisation event, not just an execution detail.

Identity blast radius becomes the right concept for multi-agent security. In a delegation chain, one over-broad grant can move farther than the original operator intended because each hop can inherit enough context to continue. That makes the blast radius of an agent access decision larger than the first resource touched. The practitioner conclusion is to evaluate agent controls by how far scope can travel, not only by what content is blocked at the edge.

Hierarchical traces improve visibility, but visibility is not governance. A trace can show which agent handed off to which other agent, yet that record arrives after execution has already happened. Governance has to decide whether each hop remains within the original intent before the task continues. The practitioner conclusion is that observability should support authorisation, not be mistaken for it.

AI agent security now requires a separate policy for delegation chains. The article shows why single-request guardrails leave a gap once work moves across multiple agents and tool calls. That gap sits between inline content enforcement and access control, which is where many current programmes are least mature. The practitioner conclusion is to make delegation-specific governance a first-class control domain rather than an extension of monitoring.

What this signals

Delegation chain governance is the missing control layer for many agentic programmes. Teams are increasingly adding prompt filters and traceability, but those controls do not answer whether a downstream agent is still acting within the original authority. The practical shift is toward enforcing purpose and scope at each hop, not only at request entry.

AI agent security should be measured by scope containment, not by content rejection rates. A system that blocks obvious unsafe text can still allow a tool call that was never authorised for the task. The programme signal to watch is whether access decisions remain in force after delegation, because that is where trust most often expands unnoticed.

For practitioners

• Separate content policy from access policy Document which decisions are about text safety and which are about data or tool authorisation. Then enforce them at different points in the execution path so a safe prompt cannot bypass an unauthorised access check.
• Bind agent access to declared purpose Require each agent request to carry a declared purpose and a short-lived scope, and reject requests that reuse standing access for tasks outside that purpose. This keeps the access decision tied to the work being done.
• Treat every hop as a new authorisation event For A2A flows, decide whether each handoff may inherit context, reach new tools, or touch new datasets before the next agent executes. Do not let a successful first hop imply permission for the rest of the chain.
• Audit where identity disappears in delegation chains Map the point at which the original identity, purpose, or scope is no longer enforced across agent handoffs. That is the place where task execution can drift beyond the intended boundary.

Key takeaways

• AI agent security is split between content filtering and access authorisation, and treating them as the same control leaves a governance gap.
• Delegation chains matter because the original identity and purpose can erode across hops even when each individual request looks safe.
• Practitioners need controls that re-check scope at handoff, not just at the first request, or agentic systems will carry excessive access farther than intended.

Key terms

• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Purpose-Based Access: An access model that allows or denies AI use based on why the request is being made, not only who the requester is. It is more precise than role alone because it can combine identity, data labels, and request context to control sensitive AI interactions at runtime.
• Content Guardrails: Content guardrails are policy rules that inspect prompts or outputs and block material that violates organisational standards. They can filter topics, keywords, or content categories before a model processes the request. This gives compliance and legal teams direct control over what the AI layer is allowed to handle.
• Context propagation: The passing of prior conversation, data, or state between tools or sessions so an actor can make use of it later. In agentic environments, context can become an access multiplier if it helps the system infer, trigger, or justify actions beyond the original request.

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 programme, it is worth exploring.