Authentication answers whether the agent can prove its identity, but agentic AI can still take actions that exceed the original intent of that identity. The risk appears after login, when tool use, delegation, and chained actions expand the effective permission boundary. That is why authorisation must operate continuously, not only at issuance.
Why authentication is only the starting point
Authentication establishes that the agent presented valid proof of identity, but it does not limit what that identity can do once it is trusted. For agentic AI, the real risk starts after login, because the agent may invoke tools, chain actions, or act on delegated authority that expands the effective permission boundary far beyond the original sign-in event.
That is why authentication alone cannot answer the access-control question. A system can correctly identify the agent and still fail to constrain the actions that follow, especially when the agent can call APIs, access shared workspaces, or trigger downstream systems without fresh policy checks.
In practice, this means access control has to be tied to intent, scope, and action, not just to the initial proof of identity. The control objective is not merely “who are you?” but “what may you do right now, in this context, with this tool, on this data, for this task?”
Authentication and authorisation therefore solve different problems. Authentication creates a trusted starting point; authorisation governs whether each action remains within the approved boundary as the agent moves through tools, prompts, memory, and workflow steps.
Where agentic systems break the authentication-only model
Agentic systems often operate through chained decisions, delegated credentials, and tool use that make the original login event a weak predictor of later behaviour. An agent may begin with a narrowly intended task, then reach a broader outcome through retrieval, retries, multi-step execution, or interaction with another system that inherits trust from the first step.
This is especially visible when an agent can act through a human user’s session, a service token, or an integration credential that was never meant to authorise the full action set the agent can reach. The problem is not only compromise, but overreach: the identity may be valid while the resulting action is still unsafe.
Good access control for this environment therefore has to follow the action path. For a deeper treatment of that model, see AI Agent Authorisation Guide, which focuses on least privilege, task-scoped access, and per-action decisions. It also helps to separate the identity concept from autonomy level, which is covered in AI Agents vs Agentic AI.
In environments with multiple handoffs or delegated steps, the question is not whether the agent authenticated once, but whether every significant action remains authorised after the context changes. That is the control gap authentication cannot close by itself.
What continuous authorisation has to cover
Continuous authorisation means the policy decision must remain live across the agent’s runtime, not frozen at issuance. Each tool call, scope expansion, privilege escalation, or sensitive data access should be checked against the current task, current context, and current trust boundary.
That usually requires explicit limits on delegated authority, tighter control of tool permissions, and a clear rule for when a human approval step is needed. Authentication can prove that the agent began in a trusted state, but only ongoing authorisation can constrain what happens when the agent changes path, retries a task, or encounters a new system.
For practitioners, the most useful mental model is to treat agentic access as an execution chain, not a static session. The chain can remain legitimate while still becoming more powerful than intended, which is why the access decision has to be evaluated repeatedly rather than assumed from the first login.
That runtime view aligns with NIST AI Risk Management Framework, which frames AI risk as something to govern across the system lifecycle, and with OWASP Agentic AI Top 10, where identity and privilege abuse is a distinct agentic risk area.
Risk and Threat Considerations
Authentication-only designs create a false sense of safety because they assume a valid identity implies safe behaviour. In agentic systems, that assumption fails when an attacker, a malformed prompt, or an overly broad delegation path turns a trusted agent into a vehicle for unintended actions.
Failure mechanism: The agent keeps a valid identity while its runtime permissions, tool access, or delegated scope exceed the original intent, allowing tool misuse, privilege expansion, or chained action abuse after successful authentication.
Impact: The result can be unauthorised data access, unexpected system changes, harmful external actions, or lateral movement through trusted integrations without any additional login event to trigger suspicion.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic access can exceed intended authority after authentication. |
| ASI02 — Tool Misuse | Authenticated agents can still misuse tools beyond intended scope. | |
| Recommendation — Enforce per-action checks to prevent identity-driven privilege expansion. Restrict tool access to task-scoped permissions and approvals. | ||
| NIST SP 800-53 Rev 5 | IA-9 — System and Services Authentication | Agent-to-service trust needs more than a one-time login. |
| AC-6 — Least Privilege | Continuous authorisation requires limiting what the agent can do. | |
| AU-2 — Audit Events | Runtime authorisation depends on observable tool and action events. | |
| Recommendation — Authenticate services and agents with bounded, verifiable trust relationships. Grant only the minimum permissions needed for each agent task. Log agent actions at the point of decision and execution. | ||
Practitioner Guidance
What to prioritise: Treat every sensitive tool call as a new authorisation decision, not a continuation of the original login. If the action affects data, money, production systems, or external side effects, require a policy check that is narrower than the agent’s general identity.
What to verify: Confirm that the agent’s effective permissions are task-scoped, time-bounded, and visible in logs. You should be able to show which approval covered the action, which tool was allowed, and why the request stayed within scope.
Common mistake: Relying on SSO or a valid bearer token as proof that the agent may keep acting. That only proves initial authentication, not continuing entitlement.
Practitioner takeaway: The safest design is one where authentication opens the door, but authorisation continuously decides which rooms the agent may enter as its task unfolds.
Framework alignment: Map agent runtime checks to NIST SP 800-53 IA-5 for credential lifecycle, IA-9 for system and service authentication, and AC-6 for least privilege.
Related resources from NHI Mgmt Group
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- When is it crucial to implement least-privilege access for AI agents?
- When does AI agent access create more risk than it reduces?
- What is the difference between governing human access and governing AI agent access?