Zero trust assumes continuous verification of who or what is requesting access, but AI agents can chain actions, infer context, and reuse privileges in ways traditional sessions do not. That means trust must be checked at the workload, action, and approval levels, not only at login. The result is more granular policy, not weaker security.
Why Autonomous AI Agents Break Traditional Zero Trust Assumptions
zero trust works best when the thing asking for access has a stable identity, a predictable purpose, and a narrow set of actions. AI agents disrupt all three. They can interpret a goal, choose tools, chain requests, and reuse privileges across steps in ways that a normal user session never would. That makes login only the first checkpoint, not the real security boundary.
This is why agentic security guidance increasingly treats the agent as a workload, not just a user substitute. The practical challenge is closer to NHI governance than to classic human IAM. The OWASP NHI Top 10 and the OWASP Agentic AI Top 10 both reflect the same issue: once an agent can reason and act, policy has to follow intent, context, and execution path rather than static role membership.
NHIMG research shows the scale of the identity problem is already severe: 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, yet most organisations still lack mature NHI controls. In practice, many security teams discover this gap only after an agent has already chained access through multiple systems, rather than through intentional design.
How It Works in Practice
The operational shift starts by separating identity from authorization. For agents, identity should be workload-based and cryptographic, while authorization should be evaluated at request time. That means using workload identity primitives such as SPIFFE/SPIRE, short-lived OIDC tokens, or similar attestable identities so the platform knows what the agent is, not just what password or API key it borrowed. The Guide to SPIFFE and SPIRE is useful here because it shows how ephemeral workload identity can replace long-lived secrets that are too easy for agents to reuse.
From there, policy needs to move from RBAC-only thinking to intent-based or context-aware authorization. An agent trying to read a ticket is not the same as an agent trying to modify production data, even if both actions come from the same process. Best practice is evolving toward policy-as-code and real-time evaluation, using tools and models aligned to NIST AI Risk Management Framework and NIST SP 800-207 Zero Trust Architecture. That gives security teams a way to check purpose, data sensitivity, tool scope, and environmental signals before the action is approved.
A practical control pattern looks like this:
- Issue JIT credentials for one task, not standing access for an entire session.
- Bind secrets to the smallest viable scope and revoke them automatically when the task ends.
- Log every tool call, data touchpoint, and approval step for audit and rollback.
- Require human approval for high-risk actions such as exfiltration, privilege changes, or payment instructions.
This is where NHI governance becomes essential. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes long-lived agent permissions especially dangerous. These controls tend to break down in environments where agents are allowed to call many tools across fragmented SaaS and cloud estates because the approval path becomes too broad to enforce consistently.
Common Variations and Edge Cases
Tighter agent controls often increase latency and operational overhead, so organisations have to balance speed against containment. That tradeoff is real, especially when agents are embedded in customer support, DevOps, or software delivery workflows where actions happen quickly and repeatedly. There is no universal standard for how much autonomy an agent should receive, so current guidance suggests starting with low-risk tasks and expanding only after telemetry proves the workflow is stable.
Two edge cases matter most. First, multi-agent systems can create privilege amplification when one agent inherits context from another and the original intent is lost. Second, agents that interact with legacy systems often force teams back into broad service accounts, which weakens zero standing privilege. In those cases, JIT credentialing and short TTL secrets remain the best available pattern, but they need to be paired with strict output controls and approval checkpoints. The CSA MAESTRO agentic AI threat modeling framework is a good reference for thinking through those chains of responsibility.
NHIMG’s research also shows why this matters now: 80% of organisations report their AI agents have already performed actions beyond intended scope, including revealing credentials and accessing unauthorised systems. That lines up with the practical advice in the OWASP Agentic AI Top 10 and makes one point clear: zero trust is still valid, but for agents it must be enforced at the workload, action, and approval layers, not only at the point of authentication.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Autonomous agents can exceed intended scope and chain risky actions. |
| CSA MAESTRO | MAESTRO models agent trust, autonomy, and control gaps across workflows. | |
| NIST AI RMF | GOVERN | AI RMF governance fits accountability for autonomous agent decisions. |
Assign ownership, monitoring, and escalation paths for every production agent.
