Setup-time authorisation fails because it answers only whether the identity may connect, not whether a later action still fits the approved purpose. With AI agents, the risky decision happens inside the session, after the token has already been accepted. That is why runtime policy, intent review, and behavioural checks must govern the actual call, not just the login event.
When runtime discretion fails, the token is not the control
Valid credentials prove that an agent can be authenticated, but they do not prove that the next action still matches the approved purpose. The security failure is a mismatch between possession of access and permission to exercise it in that specific moment. For AI agents, that gap matters because the decision is made after login, inside the session, where policies must follow the action.
That is why a setup-only model is too weak for agents. If the runtime can still choose arbitrary tools, scopes, prompts, or workflows, then the credential has become a pass to act, not a bound on what may be done.
Why setup-time authorisation breaks down for AI agents
Setup-time authorisation answers a narrow question: may this identity connect, and under what broad terms was access granted? It does not fully answer whether a later call is still safe after the agent has seen fresh context, new data, or a changed task. That distinction is central for autonomous or semi-autonomous systems, because the risky behaviour often emerges during tool use, not at sign-in.
This is also where intent drift appears. An agent can start within a valid session and still take an action that is technically within its token scope but operationally outside the human-approved purpose. The control problem is therefore not just authentication, it is ongoing authorisation of each material action.
Runtime discretion becomes dangerous when the agent can chain benign permissions into a harmful result. A single accepted login can enable data access, file changes, external requests, or destructive tool use unless the platform re-checks intent at the point of execution.
What runtime policy has to govern instead
The right control plane is per-action and context-aware. A runtime policy should evaluate the requested action, the current task, the data or system being touched, and any delegation boundary before allowing the call. In practice, that means treating authorisation as a live decision, not a one-time gate.
- Use task-scoped permissions so the agent only holds the narrow access needed for the current objective.
- Require intent review or approval for actions that change state, expose data, or cross trust boundaries.
- Apply behavioural checks to detect when an agent is about to do something inconsistent with prior context or policy.
For agentic systems, this is where externalized authorisation patterns become more useful than static role checks alone. A policy decision at runtime can still honour identity, but it must judge the specific action, not merely the authenticated session.
Risk and Threat Considerations
When an agent can keep acting after a valid login, the main exposure is privilege misuse at runtime. The token may be legitimate, yet the action can still be abusive, destructive, or outside scope if the agent is tricked, overconfident, or simply too broadly empowered.
Failure mechanism: The system trusts session establishment more than per-action intent, so a compromised prompt, poisoned context, or overly broad tool grant can turn valid credentials into unsafe execution authority.
Impact: An attacker or faulty agent can exfiltrate data, change records, trigger external side effects, or create a blast radius that looks authorised until the exact action is reviewed.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime discretion failures let agents abuse valid identity and privilege at execution time. |
| ASI02 — Tool Misuse | Unsafe discretion often appears when an agent uses approved tools in an unsafe context. | |
| ASI09 — Human-Agent Trust Exploitation | The issue is often a trust gap between approved access and later harmful action. | |
| Recommendation — Enforce per-action policy checks to prevent valid agent credentials from enabling unsafe privileges. Gate each tool call against current intent and task scope before execution. Require human approval for high-impact actions that exceed routine agent autonomy. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits what a validly authenticated agent can do if runtime discretion goes wrong. |
| IA-5 — Authenticator Management | Valid credentials are part of the problem, but lifecycle alone does not control runtime misuse. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Runtime discretion failures demand traceable evidence of what the agent did and why. | |
| Recommendation — Reduce agent permissions to the minimum needed for the current task. Manage agent credentials tightly and rotate or revoke them when scope changes. Log and review agent actions to detect misuse that occurred after authentication. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The subject is a classic verify-each-action problem rather than trust-at-login. |
| Recommendation — Verify the request continuously and do not let prior authentication imply future authority. | ||
| OWASP ASVS | V8 — Authorization | The core failure is a gap between authenticated access and action-level authorisation. |
| Recommendation — Require action-level authorization checks for every sensitive operation. | ||
Practitioner Guidance
What to prioritise: Separate “may connect” from “may act” in your design reviews. If a control only checks authentication at session start, treat that as insufficient for agents that can invoke tools, mutate state, or call external systems.
What to verify: Confirm that high-impact actions are re-authorised at runtime against current task context, not inherited automatically from the original token. If the agent can reach production systems, verify that each state-changing action has an explicit policy checkpoint.
Decision rule: If the action can create external, financial, operational, or data-loss impact, require a runtime control that evaluates intent and scope before execution. If it cannot be meaningfully bounded that way, reduce the agent’s discretion instead of widening its credentials.
Practitioner takeaway: For AI agents, credentials establish who entered the room, but runtime authorisation must decide whether each move is still allowed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org