Per-request checks make each tool call the unit of authority, which is necessary when an agent can query databases, invoke APIs and delegate work mid-session. Session tokens assume stable human behaviour over time. Agents do not behave that way, so the control has to evaluate the current action, not the original login.
Why per-request checks beat session-wide trust for AI agents
Session tokens were designed around a relatively stable user session, where the same person keeps the same intent, privileges and context for the duration of the login. AI agents are different: they can switch tasks, call tools, inherit delegated authority, and change blast radius mid-session. The practical question is not whether the agent is “logged in”, but whether each specific action is still allowed.
A per-request model treats every tool call, API call or delegated action as a fresh authorization decision. That matters because the risk is not only who started the session, but what the agent is trying to do right now, against which system, with which scope, and under what constraints. That is why per-action checks are a better fit for agentic systems than assuming a once-approved session stays safe.
For AI agents, session tokens are often too blunt as the main control plane. They are useful for establishing an authenticated context, but they do not express the full decision boundary needed for runtime authority. If an agent can browse, retrieve, write, delegate, and act on behalf of a user, the control has to evaluate the request itself, not merely the existence of a prior login.
What changes when the requester is an agent, not a person?
The biggest change is that the unit of trust becomes the action, not the session. A human user usually behaves within a narrower intent window, but an agent may chain unrelated operations in one run, shift from read to write permissions, or reach into systems that were never part of the original task. That makes session-wide trust a poor proxy for current risk.
Per-request checks also help separate authentication from authorization. A session token can tell you that a principal was admitted earlier, but it does not answer whether the present request should be permitted, whether the target system matches the intended scope, or whether the action is safe in this context. For agentic workflows, those are the questions that matter.
This is especially important when the agent is using delegated authority or interacting with multiple tools. The same session may contain low-risk queries, high-risk write operations and cross-system actions, but the approval standard should not stay frozen. Good controls force the system to reassess scope, target and privilege each time the agent crosses a meaningful boundary.
Per-request checks also reduce the risk of stale privilege. If an agent’s context changes, or if a delegated task expands beyond the original approval, a session token alone can keep authorizing actions that are no longer appropriate. Request-level evaluation makes it possible to tighten access as the work unfolds.
What good control looks like in practice
Per-request checks work best when the authorization decision is explicit and observable. The system should know what action is being requested, what resource is being targeted, whether the actor is acting on behalf of someone else, and whether the requested scope matches the approved task. If any of those change, the decision should be re-evaluated rather than inherited from the original session.
That is why per-action authorization patterns are a better fit than blanket session trust. NHIMG’s AI Agent Authorisation Guide frames this around least privilege, task-scoped access and human approval where needed. The core idea is to bind authority to the specific work item, not to the whole login.
For teams designing agentic systems, the practical outcome is tighter blast-radius control. Zero Trust for AI Agents applies the same logic by verifying the agent, principal and request each time, which is exactly what per-request checks need to do when autonomy rises and the action mix changes.
Per-request control also makes audit and containment more meaningful. NHIMG’s AI Agent Observability, Audit and Incident Response Guide emphasizes attribution and revocation because you cannot defend what you cannot tie to a specific action. If a session is all you can see, you have far less ability to explain or stop a bad call mid-stream.
Risk and Threat Considerations
Session tokens are attractive to attackers and unsafe as the sole guardrail because they can outlive the intent that created them. If a token is replayed, over-scoped, or reused after the agent’s task has changed, the attacker or the misbehaving agent inherits more authority than the current action deserves. In agentic systems, that can turn a single approved login into a broad, persistent access path.
Failure mechanism: The control fails when the system treats a previously issued token as sufficient proof for every later tool call, even after the agent changes target, context or delegation state. That allows privilege drift, confused-deputy behaviour and unintended cross-system actions to continue without a fresh decision point.
Impact: The result is wider blast radius, harder revocation, and more damaging compromise if the agent is tricked, misrouted or abused. Per-request checks limit how far a stolen or stale authority can travel, and they make abuse visible at the moment the risky action is attempted rather than after the session is over.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Per-request checks limit agent privilege abuse at each action. |
| ASI02 — Tool Misuse | Request-level checks reduce unsafe tool invocation by agents. | |
| ASI09 — Human-Agent Trust Exploitation | Session trust can be abused when humans over-trust an active agent session. | |
| Recommendation — Enforce per-action authorization so each agent call is re-evaluated before execution. Gate every tool call against the current task scope and permitted tools. Add approval checkpoints where agent actions can materially affect user intent or assets. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Per-request authorization operationalizes least privilege for agent actions. |
| IA-5 — Authenticator Management | Session tokens and other authenticators need lifecycle and use controls. | |
| Recommendation — Limit each agent action to the minimum permissions needed for that request. Manage token issuance, scope and rotation so credentials cannot be reused broadly. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Continuous verification fits per-request checks for autonomous agents. |
| Recommendation — Verify each request independently instead of trusting a prior session state. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent sessions can silently accumulate too much authority across requests. |
| NHI-07 — Long-Lived Secrets | Long-lived session tokens can outlast the task and increase replay risk. | |
| Recommendation — Audit agent permissions regularly and remove any standing access beyond current need. Prefer short-lived credentials and re-check authority before each sensitive action. | ||
Practitioner Guidance
What to prioritise: Put the strongest checks at the highest-risk transitions, such as write actions, delegation steps, cross-environment calls and anything that touches sensitive data or production systems. A read-only query and a destructive API call should not share the same trust level just because they came from the same session.
What to verify: Confirm that the authorization decision includes current action, target resource, actor context and delegated scope. If your logs only show “session active”, you do not yet have enough evidence to prove that the agent was constrained at the moment it acted.
What practitioners underestimate: Session validity is not the same as action validity. The most common mistake is to treat authentication as if it were sufficient authorization, then discover too late that the agent’s authority expanded faster than the original login model could express.
Practitioner takeaway: For AI agents, the safe design principle is to re-authorize the action, not trust the session, because the risk changes with every tool call.
Related resources from NHI Mgmt Group
- How can organisations govern AI agents that use service accounts and tokens?
- Why do session-level evaluations matter for AI agents compared with trace-level checks alone?
- When is it crucial to implement least-privilege access for AI agents?
- What is the difference between managed identities and hardcoded secrets for AI agents?