AI agents complicate zero trust because they are dynamic, autonomous, and capable of making new tool requests as conditions change. Traditional NHI controls often assume fixed purpose and predictable access patterns. Zero trust still applies, but it must be implemented with continuous verification, scope limits, and explicit policy enforcement for each action.
Why This Matters for Security Teams
AI agents change the control problem because the identity is no longer attached to a predictable workflow. An agent can decide to call a different tool, request a new token, or chain actions that were not known at design time. That makes static RBAC and long-lived secrets a poor fit for autonomous behaviour. The practical risk is visible in agent deployments that have already stepped outside intended scope, which is why the issue is now treated as an identity problem as much as an AI problem. The need for stronger governance is echoed in the OWASP NHI Top 10 and the OWASP Agentic AI Top 10, while NIST’s zero trust model makes clear that every request must be verified in context, not trusted because the caller is “known.”
NHIs also remain a broad exposure point in many environments. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which is a direct problem when an agent can choose from multiple tools and permissions in real time. In practice, many security teams encounter agent overreach only after sensitive data has been accessed or an unexpected action has already completed, rather than through intentional policy design.
How It Works in Practice
Effective agent control starts by treating the agent as a workload identity, not as a user with a fixed role. That means cryptographic identity, short-lived credentials, and policy checks that run at request time. Current guidance suggests pairing zero standing privilege with just-in-time issuance so the agent receives access only for the specific task, then loses it immediately after completion. This is where Guide to SPIFFE and SPIRE becomes relevant: workload identity helps prove what the agent is, while not assuming what it will do next.
In operational terms, the control stack usually needs four layers:
- Intent-based authorisation that evaluates the action the agent is attempting, not just its assigned role.
- JIT credentials and ephemeral secrets with strict TTLs, so tokens are task-bound and automatically revoked.
- Policy-as-code at runtime, using tools such as OPA or Cedar, so decisions can reflect current context, data sensitivity, and transaction scope.
- Logging and auditability for every tool call, secret request, and data access event.
This approach aligns with the NIST AI Risk Management Framework and NIST SP 800-207 Zero Trust Architecture, both of which emphasise continuous evaluation and explicit trust decisions. It also matches NHI Mgmt Group research on agent overreach, where 80% of organisations report agents have already acted beyond intended scope. These controls tend to break down when agents inherit broad platform permissions from CI/CD pipelines or shared service accounts because the policy decision becomes detached from the actual action being attempted.
Common Variations and Edge Cases
Tighter control often increases orchestration overhead, requiring organisations to balance safer execution against latency, developer friction, and incident response speed. That tradeoff is especially visible in multi-agent systems, where one agent may request access on behalf of another and the trust boundary becomes blurred. There is no universal standard for this yet, so best practice is evolving rather than settled. The CSA MAESTRO agentic AI threat modeling framework is useful here because it pushes teams to map tool use, memory, and escalation paths instead of treating the agent as a single static principal.
Edge cases also include long-running agents, agents that operate across multiple environments, and systems that need access to customer data, code repositories, or admin APIs. In those cases, a single credential with a broad TTL is usually the wrong pattern. NHI Mgmt Group’s research notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which matters even more when an agent can generate new access demand autonomously. For implementation detail, the Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both support the same practical lesson: treat agent permissions as a continuously reviewed control surface, not a one-time provisioning event.
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 | A3 | Addresses agent overreach, tool misuse, and runtime authorization failure. |
| CSA MAESTRO | GOV-2 | Covers governance for autonomous agents and their tool-access boundaries. |
| NIST AI RMF | Supports risk governance for dynamic AI behaviour and accountability. |
Apply AI RMF governance to define ownership, monitoring, and escalation for agent actions.
