Why do AI agents break traditional token and session models?

Why Traditional Token and Session Models Break Down for AI Agents

Traditional token and session designs assume a human user, a bounded task, and a mostly stable request pattern. AI agents do not behave that way. They can chain tools, change audiences, and make follow-on calls that were never explicit at session start. That means a token that looked safe for one action can silently become authority for several unrelated actions. This is why delegated token exchange and runtime authorisation are becoming central to agent security, as reflected in the OWASP Agentic AI Top 10 and NHI guidance from OWASP NHI Top 10.

The practical failure is not just over-privilege. It is ambiguity. If one bearer token is reused across multiple tool calls, post-incident review can no longer tell which action was intended, which was inferred, and which was triggered by prompt injection or tool misuse. That is why the industry is moving toward context-aware, short-lived authority rather than session-long trust. In practice, many security teams discover this only after an agent has already acted outside scope, rather than through intentional design review.

How It Works in Practice

For agentic systems, the safer pattern is to bind identity and privilege to the task, not to the session. Current guidance suggests treating the agent as a workload identity, then issuing a fresh capability only when the next step is approved. That usually means short-lived tokens, delegated token exchange, and policy checks at request time rather than static entitlement at login. The goal is to make each action visible, explicit, and revocable.

A practical implementation often combines several controls:

• Use workload identity for the agent itself, so the system knows what it is, not just what secret it holds.
• Issue just-in-time credentials with narrow scope and short TTL, then revoke them after the task completes.
• Evaluate policy in real time using policy-as-code, so the agent’s tool, data, and destination are checked at the moment of use.
• Split broad workflows into discrete exchanges so an agent cannot reuse one token across unrelated tools or audiences.
• Log every delegated hop for auditability and reconstruction.

This approach aligns with the reasoning in NIST AI Risk Management Framework and the agent-security focus of CSA MAESTRO agentic AI threat modeling framework. It also reflects incident patterns documented in AI Agents: The New Attack Surface report, where agents performed actions beyond intended scope and exposed sensitive data or credentials.

These controls tend to break down in long-running autonomous workflows with shared toolchains, where one agent’s context is inherited by another and token boundaries blur across services.

Common Variations and Edge Cases

Tighter delegation often increases orchestration overhead, requiring organisations to balance security against latency, developer complexity, and operational reliability. That tradeoff is real, especially in systems that need to act quickly across many tools.

Not every agent needs the same token model. A read-only summariser may be adequately protected with short-lived scoped access, while a code-writing or remediation agent needs stricter step-up approval and finer-grained constraints. Best practice is evolving, but there is no universal standard for this yet. What is consistent is that static, reusable bearer tokens are a poor fit when the agent can decide its own next move.

Two edge cases deserve special attention. First, multi-agent pipelines can accidentally amplify privilege if one upstream agent passes an overly broad credential downstream. Second, some environments still rely on legacy session assumptions, which makes token exchange difficult until identity, policy, and audit logging are redesigned together. NHIMG’s reporting on CoPhish OAuth Token Theft via Copilot Studio shows how easily agent workflows can be turned into credential theft paths when trust is granted too broadly.

For threat modelling, the right question is not whether a token is valid at session start, but whether it should still be valid for the next action. That distinction is now central to agent security, as shown in the MITRE ATLAS adversarial AI threat matrix and NHIMG coverage of the OWASP Agentic Applications Top 10.

Related resources from NHI Mgmt Group

• Why do AI agents create a different access-risk profile than traditional applications?
• Why do AI agents break traditional identity and access management models?
• Why do AI agents break traditional IAM and RBAC models?
• Why do AI agents break traditional fraud detection models?