They complicate access control because behaviour is probabilistic, not fixed, so the same inputs can lead to different actions. They complicate auditability because teams need evidence of what the agent saw, chose and executed, not just the final answer. That shifts control design toward traceable runtime authority rather than static permission lists.
Why This Matters for Security Teams
agentic ai systems are not just another application tier. They can plan, call tools, chain actions, and change course mid-task, which means access decisions cannot rely on a fixed job function or a preapproved path. That creates a control gap between what an agent is allowed to do in theory and what it can actually do at runtime.
This is why current guidance increasingly centers on runtime authority, not static entitlements. Frameworks such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same operational problem: an agent can decide to act outside the exact scenario that was modeled during design. In NHI terms, that makes long-lived credentials and broad RBAC assignments especially risky, because the identity may be legitimate while the behavior is not.
NHIMG research on the AI Agents: The New Attack Surface report found that 80% of organisations report their AI agents have already performed actions beyond their intended scope, while only 52% can track and audit the data those agents access. In practice, many security teams discover this gap only after an agent has already touched data, chained tools, or attempted an action no reviewer expected.
How It Works in Practice
The practical response is to treat the agent as a workload with cryptographic identity and tightly scoped runtime authority, not as a human user with a permanent role. That means using workload identity primitives, short-lived tokens, and policy evaluation at request time. Standards work around OWASP Non-Human Identity Top 10 and implementation guidance from CSA MAESTRO agentic AI threat modeling framework both reinforce this direction.
Operationally, security teams should expect these controls:
- Issue JIT credentials per task, with a short TTL and automatic revocation when the task ends.
- Bind permissions to the agent, the tool, the data class, and the specific user intent being executed.
- Prefer policy-as-code and real-time authorization checks over static allowlists that assume a predictable workflow.
- Log the agent’s inputs, retrieved context, tool calls, intermediate decisions, and outputs, not just the final response.
- Separate tool access from data access so a successful prompt cannot silently become broad system authority.
This is also where auditability changes shape. A usable audit trail must show what the agent saw, which policy allowed each action, and which secret or token was used at that step. NHIMG coverage of the OWASP NHI Top 10 and the Analysis of Claude Code Security both show that chaining tools without per-step traceability makes incident review and containment far harder.
These controls tend to break down when agents operate across multiple SaaS systems with weak token scoping and inconsistent logging, because the runtime decision chain becomes fragmented across vendors and teams.
Common Variations and Edge Cases
Tighter runtime authorization often increases latency, policy complexity, and operational overhead, so organisations have to balance control depth against usability and automation speed.
One edge case is the difference between read-only retrieval and action-taking agents. A summariser with limited context may only need narrow data access, while an agent that can open tickets, move money, or modify code needs explicit step-level approval gates. Another is delegated delegation: an agent that can spawn sub-agents or call external tools may inherit or amplify privileges unless each hop is independently constrained. Current guidance suggests treating this as a design-time risk, not just an incident-response issue, but there is no universal standard for exactly how much trace data must be retained.
For high-risk workflows, best practice is evolving toward zero standing privilege, contextual approval, and evidence-rich logging aligned to the NIST Cybersecurity Framework 2.0. NHIMG’s Moltbook AI agent keys breach and CoPhish OAuth Token Theft via Copilot Studio illustrate a recurring pattern: once a long-lived token exists, the agentic control problem becomes an identity problem, an audit problem, and a containment problem at the same time.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Dynamic agent behavior undermines static access assumptions. |
| CSA MAESTRO | TRUST-04 | Addresses threat modeling for autonomous tool-using agents. |
| NIST AI RMF | Requires governance for unpredictable AI behavior and accountability. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived credentials reduce blast radius for agent workloads. |
| NIST CSF 2.0 | PR.AA-01 | Supports identity-aware access control and evidence collection. |
Review agent actions at runtime and constrain tool use to the exact task context.
Related resources from NHI Mgmt Group
- Why do agentic AI systems need NHI-style access controls?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
