Because their behaviour is not always stable enough for static role design to remain accurate. When an identity can change intent or execution pattern in real time, the original permission model may no longer describe the actual risk. Teams need a decision model that evaluates current context, not only assigned access.
Why This Matters for Security Teams
Preapproved permissions work only when the identity’s behaviour is predictable. AI agents and other NHIs do not stay within fixed execution paths, which makes static IAM a poor proxy for actual risk. A role can be correct at provisioning time and still be unsafe when an agent changes tools, follows a new prompt chain, or starts acting on a different task than the one originally approved.
This is why current guidance increasingly pushes teams toward runtime decisions, short-lived credentials, and workload identity. The issue is not just access volume, but access volatility. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which aligns with the idea that trust must be evaluated continuously, not assumed from assignment alone.
In practice, many security teams encounter privilege misuse only after an agent has already chained tools or reused a secret in a way nobody intended.
How It Works in Practice
For agentic systems, the identity problem is less about who is allowed and more about what the software is trying to do right now. Static RBAC still has a place for baseline governance, but it does not describe the moving target created by autonomous execution. That is why security teams are adopting intent-based or context-aware authorisation, where policy is evaluated at request time using the task, data sensitivity, destination service, and environment context.
In practice, that means pairing workload identity with ephemeral access. A good control pattern is: authenticate the agent as a workload, issue a short-lived token or secret only for the current task, scope it to one service or one data path, and revoke it automatically when the task ends. Frameworks such as NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework both support this shift toward runtime control and explicit risk treatment.
- Use workload identity, such as SPIFFE/SPIRE or OIDC-backed service identities, so the agent proves what it is before it receives access.
- Evaluate policy at the moment of action with policy-as-code tools rather than relying only on preapproved entitlements.
- Issue JIT credentials with tight TTLs and scope them to a single purpose, connector, or dataset.
- Log tool calls, decision context, and credential issuance together so investigators can reconstruct the chain of autonomy.
This approach maps closely to the risk patterns documented in the OWASP NHI Top 10 and the OWASP Agentic AI Top 10, where over-broad access and tool misuse are treated as primary failure modes. These controls tend to break down in legacy environments that cannot issue short-lived tokens or enforce policy at the API gateway because access is hard-coded into long-lived service accounts.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance stronger containment against latency, integration complexity, and developer friction. That tradeoff is real, especially where agents must coordinate across many services or run continuously.
There is no universal standard for this yet, so guidance remains mixed on how far to push dynamic authorisation versus preapproved boundaries. In high-assurance environments, the safer pattern is to keep static permissions minimal and let runtime policy narrow access further based on current intent. In lower-risk workflows, some teams use coarse preapproval plus JIT secrets to reduce churn, but that should not be confused with true autonomy-safe governance.
Edge cases matter. Long-running agents can outlive their original context, so token TTL must reflect task duration and not human shift length. Multi-agent pipelines are even harder because one agent can inherit assumptions from another and amplify a mistake across chained tool calls. The NHI Mgmt Group’s OWASP Agentic Applications Top 10 and the NHI lifecycle guidance in Ultimate Guide to NHIs are useful references when deciding how aggressive to be with revocation, rotation, and monitoring.
Where this guidance breaks down most often is in environments that still rely on shared secrets embedded in code or CI/CD variables, because the agent can reuse them faster than teams can revoke them.
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 | NHI-01 | Agentic systems need runtime controls, not static preapproval. |
| CSA MAESTRO | AI-2 | MAESTRO models agent risk from tool use, autonomy, and context. |
| NIST AI RMF | GOVERN | AI RMF governance supports accountability for dynamic agent behavior. |
Treat every agent action as a new authorization event and scope access to the current task.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
