Where does agent authorisation fail if scope is checked only at login?

Why This Matters for Security Teams

Login-time approval is too coarse for agents because the risk is not just who started the session, but what the agent can do after it starts. A browse-only workflow can become a checkout, refund, or order retrieval workflow without any new human intent. That is why static session scope is a poor fit for autonomous or semi-autonomous execution. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime controls, not one-time authentication, for systems that can adapt and chain actions.

This is especially relevant where agents hold delegated access to customer data, payment systems, support tooling, or internal APIs. NHIMG research on CoPhish OAuth Token Theft via Copilot Studio shows how quickly delegated access can be abused once an identity is granted broader session power than the task actually needs. The control gap is not theoretical: if the login approves the person or workload once, the agent can often keep acting long after the original trust decision is stale. In practice, many security teams encounter privilege creep only after an agent has already crossed from harmless browsing into a sensitive workflow.

How It Works in Practice

Least privilege for agents has to be enforced at the tool or action level, not only at login. A safer pattern is: authenticate the workload, issue a short-lived token, then evaluate each request against the specific tool, resource, and context in real time. That aligns with the direction described in the OWASP Non-Human Identity Top 10 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize that identity alone is not enough when an agent can change objectives mid-session.

In practice, teams should separate “can log in” from “can do this action now.” The login event establishes the agent’s workload identity, but each sensitive operation should still be checked against policy. That policy can consider:

• the tool being invoked, such as browse versus checkout or order retrieval;
• the data classification of the target resource;
• the task context, including user approval, step-up requirements, or transaction amount;
• the token lifetime and whether the credential should be ephemeral;
• the agent’s current runtime state, including whether it is switching objectives.

This is why just-in-time credentialing matters. A short-lived token or scoped delegation grant limits blast radius if the agent drifts, loops, or gets prompt-injected into a higher-risk action. NHIMG’s Amazon Q AI Coding Agent Compromised coverage illustrates the broader issue: once an agent can execute tool calls, a single standing grant can become a path to unintended destructive action. These controls tend to break down in environments that rely on long-lived bearer tokens, broad service accounts, or API gateways that only inspect the initial session and not the downstream tool call.

Common Variations and Edge Cases

Tighter tool-level authorization often increases operational overhead, requiring organisations to balance friction against the need to stop agent overreach. Current guidance suggests that the tradeoff is worth it for agents that can modify records, move money, access customer data, or trigger external side effects, but there is no universal standard for how granular the policy must be yet.

Two edge cases come up often. First, read-only agents still need context-aware controls if they can pivot from search to retrieval of sensitive records. Second, multi-agent systems complicate the problem because one agent’s low-risk action can feed another agent’s higher-risk tool use. That is where runtime policy evaluation and workload identity become more important than static role assignment. The Ultimate Guide to NHIs — 2025 Outlook and Predictions reinforces that static secrets and standing access remain a recurring failure mode across machine identities. For threat modeling, teams should also compare the behaviour against the MITRE ATLAS adversarial AI threat matrix, especially where tool chaining or lateral movement is possible. The practical rule is simple: if the agent can change tasks, the authorization decision must change too.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• When do AI agent credentials create more risk than they reduce?