IAM teams should move from static allow lists to continuous authorisation for each sensitive step an agent takes. If the agent can select tools, combine actions, and decide timing at runtime, a one-time permission grant is not enough. The control has to evaluate intent and context before each high-risk action completes.
Why This Matters for Security Teams
AI agents change IAM from a static approval problem into a runtime control problem. Once an agent can pick tools, chain actions, and adjust timing on its own, a single role grant no longer predicts what it will do next. That is why guidance is shifting toward continuous authorisation, short-lived credentials, and policy decisions made at the moment of action, not at onboarding.
Traditional IAM still matters, but it is not sufficient for autonomous workloads. A role can say what an agent may generally touch; it cannot safely govern when the agent decides to query a database, call an API, export data, or invoke another agent. NHI Management Group’s research on OWASP NHI Top 10 and the broader OWASP Agentic AI Top 10 both point to the same operational issue: agents create new attack paths by combining legitimate permissions in unexpected ways.
This is not a theoretical concern. SailPoint’s AI Agents: The New Attack Surface report found that 80% of organisations say their AI agents have already acted beyond intended scope. In practice, many security teams encounter agent misuse only after the agent has already chained tools, moved laterally, or exposed data, rather than through intentional design.
How It Works in Practice
The practical shift is to treat the agent as a workload with its own cryptographic identity, then authorise each sensitive step at runtime. That means using workload identity rather than a standing human-style account, issuing ephemeral secrets with tight TTLs, and evaluating policy on every high-risk request. Current guidance from NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework supports this direction, even though there is no universal standard for agent authorisation yet.
A workable pattern usually includes:
- Workload identity for the agent, such as SPIFFE or OIDC-based service identity, so the system knows what the agent is, not just what secret it holds.
- Just-in-time credential issuance for a single task, with automatic revocation after completion or timeout.
- Policy-as-code for runtime checks, using context such as requested tool, data sensitivity, transaction value, and prior agent activity.
- Step-up controls for dangerous actions, including human approval for exports, privilege changes, or cross-domain tool calls.
- Logging that ties each action to the agent identity, prompt context, tool chain, and decision outcome.
NHI Management Group’s Ultimate Guide to NHIs and the Moltbook AI agent keys breach illustrate why long-lived credentials are a poor fit: once an agent can decide its own next move, any standing secret becomes reusable beyond the original intent. These controls tend to break down in environments where agents have broad API reach but weak telemetry, because the security team cannot reliably reconstruct which step triggered a harmful outcome.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance containment against developer velocity and agent autonomy. That tradeoff is real, especially when multiple agents collaborate or when an agent must complete a workflow across several systems without waiting for approvals at every hop.
Best practice is evolving, but a few edge cases are already clear. For low-risk retrieval tasks, short-lived tokens and coarse policy checks may be enough. For agents that can write code, move money, change infrastructure, or delegate work to other agents, continuous authorisation becomes much more important. This is where static RBAC breaks down: the role describes a broad entitlement, while the risk emerges from the sequence the agent chooses at runtime.
Another common failure mode is treating secrets management as the primary control. Secrets matter, but they are only one layer. If the agent’s identity is not bound to workload attestation and the policy engine cannot assess context in real time, a leaked token is only the beginning. The State of Secrets in AppSec research reinforces how fragmentation and delayed remediation create exposure windows that autonomous systems can exploit quickly.
Current guidance suggests IAM teams should reserve standing access only for narrowly defined, low-risk automations and push everything else toward ephemeral, context-aware decisions. That approach is strongest when agents are production-grade, tool-rich, and capable of independent planning.
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 | Agentic tool misuse and runtime action selection are the core risk here. |
| CSA MAESTRO | T1 | MAESTRO models agent autonomy, chaining, and tool-based escalation risks. |
| NIST AI RMF | GOVERN | Continuous authorisation depends on accountability, policy, and oversight. |
Model agent workflows end to end and add controls for chaining and escalation points.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
