They usually assume one stable identity making one request at a time. Agent workflows can span tools, sub-agents, and long-running tasks, so the original intent can drift while the identity remains valid. That makes static entitlements too blunt unless they are paired with delegation-aware policy and expiry.
Why Traditional RBAC and ABAC Fall Short for AI Agents
RBAC and ABAC were built for predictable request patterns: a user logs in, a role or attribute set is evaluated, and access is granted or denied. AI agents do not behave that way. They can plan, chain tools, call sub-agents, and change course mid-task, which means the same identity may need different permissions at different moments. That creates a gap between static entitlement design and dynamic execution.
NHIMG research on the OWASP NHI Top 10 and the AI Agents: The New Attack Surface report shows why this matters operationally: 80% of organisations say their AI agents have already acted beyond intended scope. Traditional access models usually treat that as an exception case, but for autonomous systems it is a design constraint. Current guidance suggests that static policy should be the baseline only for low-risk, bounded agent actions, not for open-ended workflows.
In practice, many security teams discover over-permissioning only after an agent has already accessed data, called a tool, or exposed a secret that no one expected it to touch.
How It Works in Practice
For agents, the identity question is not just who is acting, but what the system is trying to do right now. That is why many architectures are moving toward intent-based or context-aware authorisation, paired with short-lived credentials and workload identity. The goal is to evaluate the request at runtime, using task context, data sensitivity, destination system, and risk signals rather than relying only on a pre-assigned role.
That model is reflected in standards work such as the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, which both point practitioners toward runtime governance rather than fixed assumptions. In implementation terms, that usually means:
- Issuing just-in-time credentials per task, with short TTLs and automatic revocation on completion.
- Using workload identity, such as OIDC or SPIFFE-based proof, so the agent proves what it is before it receives access.
- Applying policy-as-code at request time, so evaluation can consider the agent’s current action and the target resource.
- Separating human delegation from machine execution, so a task can be constrained even when the agent identity remains valid.
For broader NHI governance context, NHIMG’s Ultimate Guide to NHIs — Standards and the AI LLM hijack breach coverage both reinforce the same lesson: once secrets are valid for too long, attacker reuse and agent misuse become the same problem. These controls tend to break down when an agent can chain multiple tools across trust boundaries because the original policy decision no longer reflects the full sequence of actions.
Common Variations and Edge Cases
Tighter runtime control often increases orchestration overhead, requiring organisations to balance reduced blast radius against latency, policy complexity, and user friction. That tradeoff is especially visible in multi-agent systems, where one agent may delegate to another or to a tool broker, and each hop needs its own trust boundary.
Best practice is evolving, but there is no universal standard for every agent pattern yet. Some environments can still use RBAC as a coarse starting point, for example for read-only retrieval agents or tightly scoped internal copilots. The control becomes insufficient when agents can initiate side effects, move laterally, or access secrets that outlive the task. In those cases, ABAC helps only if the attributes are dynamic enough to capture task context, data class, and execution risk. Otherwise, it becomes a more verbose version of the same static model.
Current guidance also suggests treating long-running workflows differently from single-shot prompts. A policy that is safe at task start may be unsafe 20 minutes later if the agent has accumulated more context, more tool access, or more opportunities to pivot. That is why NHIMG’s DeepSeek breach analysis and the Anthropic report on AI-orchestrated cyber espionage are relevant cautionary examples: once an autonomous system can adapt faster than the policy lifecycle, static access controls stop being a meaningful containment layer.
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 | A-03 | Addresses overbroad access and unsafe agent action patterns. |
| CSA MAESTRO | MAE-02 | Covers agent threat modeling and trust boundaries for delegated execution. |
| NIST AI RMF | GOVERN | Requires accountability and lifecycle governance for autonomous AI behaviour. |
Restrict agent actions to runtime-approved, task-specific permissions with explicit revocation.
