AI agents create risk because Zero Trust depends on observable patterns, and agents do not behave like people. Their access shifts with the task, they can spawn sub-agents, and they can be manipulated into acting on an attacker’s behalf. That means authentication may succeed while the real compromise happens at the instruction or delegation layer.
Why AI Agents Break Human-Centred Zero Trust Assumptions
Zero Trust was designed to reduce blind trust in users, devices, and sessions, but it still assumes a relatively stable human actor behind most requests. AI agents disrupt that assumption because one “actor” may generate many actions, switch tasks quickly, delegate work to sub-agents, or be steered through prompts and tool calls. That means the control boundary can look healthy while the real decision boundary has already moved.
In practice, the challenge is not simply that agents have access. It is that their behaviour is more variable, more transferable, and easier to repurpose than a human workflow. A permission that looks safe for a person at 9 a.m. can become unsafe once an agent begins chaining tools, retrieving context, or accepting instructions from a compromised source. NIST’s Zero Trust guidance makes clear that trust decisions must be continuously evaluated rather than assumed from a login event, which is why agentic execution creates such pressure on the model.
For teams building policy around humans, the biggest mistake is treating an agent like a faster user instead of a different trust object. In practice, many security teams discover the gap only after an agent has already been delegated enough authority to bypass the controls that were meant to constrain it.
What Actually Happens When an Agent Encounters a Zero Trust Control
In a human-centred environment, a Zero Trust policy often answers a small set of questions: who is the user, what device is in use, what is the request context, and does the request fit a known pattern. An agent complicates each of those. The “user” may be a supervising application, the device may be a service runtime, the request may be generated autonomously, and the context may change several times during a single task. That makes the policy decision less about one identity and more about a moving chain of delegation.
Agent risk appears when access is granted to the outer shell but the tool layer is not tightly bounded. The agent may call internal systems, reach external services, read sensitive context, or pass outputs into a downstream action without a human reviewing each step. If the agent can create or invoke sub-agents, the problem grows again because each delegated action can inherit trust from the parent flow even when the parent flow no longer reflects the original intention.
- Authentication can succeed while intent has already been altered.
- Authorization can look valid while the requested action is semantically unsafe.
- Logging can capture the final API call while missing the manipulated instruction that caused it.
- Policy can be correct for a person but wrong for an autonomous workflow.
That is why agentic security needs more than identity verification. It needs control over delegation, tool scope, data exposure, and action boundaries, with continuous evaluation of what the agent is allowed to decide versus what it is only allowed to suggest. The guidance breaks down when the organisation cannot distinguish harmless orchestration from a workflow that can directly change state, move data, or create new access paths.
For deeper background on the architectural model, see NIST SP 800-207 Zero Trust Architecture and, for agent-specific threat patterns, the OWASP Top 10 for Agentic Applications 2026.
Where the Human Model Still Helps, and Where It Stops Working
Tighter policy usually improves containment, but it also increases orchestration overhead, so organisations must balance fewer implicit permissions against more frequent decision points. That tradeoff is manageable for people because their tasks are slower and more legible. It becomes much harder for agents because the same task may require bursts of access, rapid tool chaining, and delegated sub-steps that do not fit a static approval model.
The human model still helps when the agent is narrow, well-scoped, and operating on low-consequence tasks where every action can be reviewed or rolled back. It stops working when the agent can act across systems, infer next steps from context, or translate a benign request into a materially different operation. That is where the environment must distinguish between intent, execution, and consequence, rather than assuming they are aligned just because a session is authenticated.
There is still industry debate about how much autonomy is safe to grant before a workflow should be treated as a non-human identity problem rather than an ordinary access-control problem. NHIMG’s view is that the moment delegation, tool use, and self-directed sequencing appear together, the question is no longer only about Zero Trust enforcement, but about whether the trust model itself is still describing the right actor.
If the environment cannot bound what the agent may invoke, what data it may carry forward, and what downstream changes it can trigger, the Zero Trust design is likely being applied at the wrong layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Agentic access must be continuously constrained by identity and authorization decisions. |
| GV.RM-01 — Risk Management Strategy | Agent autonomy changes the organisation's risk appetite for trust and delegation. | |
| Recommendation — Apply PR.AA-01 to distinguish authenticated presence from permitted agent action. Set risk tolerance for autonomous delegation before expanding agent privileges. | ||
| NIST Zero Trust (SP 800-207) | ID — Identity and Access Management | Zero Trust must re-evaluate access for non-human actors and delegated actions. |
| DP — Data Protection | Agents can expose or carry forward sensitive context across tool calls. | |
| SA — System and Application Security | Agent tool use and sub-agent creation are application security concerns, not just auth events. | |
| Recommendation — Reassess identity and access decisions at each agent action boundary. Constrain what data an agent can read, retain, and pass between tools. Bound agent tool permissions and isolate autonomous execution paths. | ||
| OWASP Agentic AI Top 10 | A1 — Agentic Identity and Access Management | The question centers on agent behaviour that exceeds human-centred access assumptions. |
| A3 — Tool Abuse and Excessive Agency | Tool chaining and unsafe delegation create the core exposure in this question. | |
| A5 — Instruction Injection and Context Poisoning | Attackers can steer agents into acting on malicious instructions or corrupted context. | |
| Recommendation — Treat agents as distinct trust objects with explicitly limited delegated authority. Restrict tool scope and review actions that can change state or create access. Harden prompts and context sources against instruction manipulation. | ||
| CSA MAESTRO | MT-02 — Agent Identity, Trust and Delegation | Agent delegation and trust boundaries are the primary architectural issue here. |
| Recommendation — Map each delegation path and limit inherited authority across agent steps. | ||
| MITRE ATLAS | AML.TA0002 — Prompt Injection | The risk includes adversarial steering of agent behavior through manipulated instructions. |
| Recommendation — Hunt for prompt-injection paths that redirect agent decisions or tool use. | ||
Practitioner Guidance
What to prioritise: Separate identity assurance from action assurance. For agentic workflows, the control question is not only “is this actor authenticated?” but “is this specific action still within the approved intent, scope, and tool boundary?”
What to verify: Confirm which decisions are human-approved, which are agent-autonomous, and which are inherited from prior steps. If those three are not explicitly distinguished, policy enforcement will usually be too coarse to stop delegated misuse.
Decision rule: Treat any workflow that can chain tools, spawn sub-agents, or alter state without step-level review as a higher-risk trust boundary, even if the underlying login and device checks are strong.
What practitioners underestimate: The most important failure is often not direct compromise of the login. It is instruction manipulation, delegation abuse, or context poisoning that turns a legitimate agent into an attacker’s execution path.
Practitioner takeaway: Zero Trust for humans is usually built around stable identity and bounded sessions; Zero Trust for agents must be built around bounded authority, constrained delegation, and continuous scrutiny of intent.
