Because they let runtime decisions, tool calls, and stateful workflows happen inside familiar development stacks, which can hide where authorisation actually occurs. When identity is embedded in code and orchestration, access can expand faster than governance can explain or certify it.
Why This Matters for Security Teams
Agent frameworks change the risk model because they do not simply store secrets or invoke APIs. They make decisions, chain tools, and continue stateful work after the original request is gone. That means identity, authorisation, and execution can drift apart. For IAM teams, the familiar controls of RBAC, static service accounts, and periodic access reviews are often too slow for autonomous workloads that can improvise and re-plan at runtime. The result is not just more access, but less certainty about who or what approved it.
This is why current guidance increasingly treats agentic systems as a distinct class of workload, not just another application pattern, as reflected in the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework. In NHI terms, this is the same control gap highlighted in NHIMG research: 88.5% of organisations say non-human IAM lags human IAM, and only 19.6% feel strongly confident in their ability to manage workload identities securely. In practice, many security teams discover the overreach only after an agent has already executed a tool chain, rather than through intentional governance.
How It Works in Practice
The core problem is that agent frameworks often hide the authorisation decision inside orchestration code, prompt logic, or middleware. A developer may think the agent has “read-only” access, but the runtime can still select tools, pass arguments, fetch context, and retry actions in ways that were never reviewed as discrete permissions. Static IAM assumes access can be mapped in advance; autonomous behaviour breaks that assumption because the access path is generated on demand.
Better practice is moving toward intent-based authorisation: the system evaluates what the agent is trying to do, in what context, and with which data, before granting access. That usually means:
- issuing JIT credentials that are short-lived and task-scoped, not long-lived service secrets;
- binding agent execution to workload identity, such as cryptographic identity for the workload rather than a shared token;
- using policy-as-code at request time so decisions reflect context, not only pre-defined roles;
- revoking access automatically when the task, session, or workflow ends.
This approach aligns with the direction of the NIST AI Risk Management Framework and the NIST Cybersecurity Framework 2.0, which both emphasise governance, traceability, and risk-informed control design. It also fits the NHI guidance in OWASP NHI Top 10 and NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks, which both treat secret exposure, over-privilege, and weak lifecycle control as recurring failure modes. These controls tend to break down when agents operate across hybrid and multi-cloud systems because policy enforcement, telemetry, and revocation are rarely uniform end to end.
Common Variations and Edge Cases
Tighter control often increases integration overhead, so organisations must balance stronger runtime governance against developer friction and latency. That tradeoff becomes especially visible in multi-agent workflows, where one agent delegates to another, or where a coding assistant, retrieval layer, and execution tool all share state.
There is no universal standard for this yet, but current guidance suggests avoiding shared static secrets and treating every privileged action as a separate authorisation event. That matters in environments where tools can reach production systems, cloud control planes, or sensitive repositories. In those cases, the practical risk is lateral movement by composition: a harmless-looking read operation becomes a write path, then a deploy path, then a data exfiltration path. NHIMG has documented how quickly this can collapse, including the Moltbook AI agent keys breach, which illustrates how exposed agent credentials can scale into broader compromise.
Where agents are embedded in developer tooling, continuous delivery, or MCP-connected workflows, teams should assume the access boundary will be probed dynamically. The safer pattern is to separate identity, secrets, and execution so that the agent proves what it is at runtime, rather than being trusted because it was once configured. For deeper context, see NHIMG’s AI LLM hijack breach analysis and the OWASP Non-Human Identity Top 10 guidance.
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 | A1 | Agentic apps need runtime authz and tool-use guardrails. |
| CSA MAESTRO | G-1 | MAESTRO maps agent threat paths and control points. |
| NIST AI RMF | AI RMF covers governance for autonomous, risk-shifting systems. |
Assign owners, define risk thresholds, and monitor agent behaviour continuously.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
