The system loses the ability to judge whether later tool calls still match the original intent. An agent can reuse valid session trust to issue broader queries, updates, or exports without a new decision point, so the control becomes too coarse for delegated execution.
Why session-start-only authorisation breaks MCP delegation
MCP authorisation is meant to be a decision point tied to what the agent is trying to do, not just who opened the session. If the check happens only once, the control no longer tracks the intent behind later tool calls, so the same trusted session can drift into broader reads, writes, or exports that were never separately approved. That is a policy gap, not a minor implementation detail.
Once a session is treated as sufficient proof for everything that follows, the system starts trusting the relationship instead of the action. That weakens the boundary between an initial, narrow approval and later operations that may touch different data, tools, or blast radii, which is why the MCP authorization specification frames servers as resource servers with audience-bound tokens rather than a one-time trust handoff.
This is especially visible when an agent performs a safe first action, then reuses the same session to request a broader query, an export, or a write operation. The original approval may still be valid as a session, but it is no longer a valid decision for the new act. In practice, the authorisation model becomes too coarse to distinguish between “continue the same task” and “use the same session to do something more powerful.”
What fails operationally when later tool calls are not re-evaluated?
The first failure is loss of intent binding. A per-session check cannot answer whether the current tool invocation still matches the user’s original scope, so it cannot enforce task-scoped delegation. That matters most when the agent can chain calls across tools, because the permission to begin work is not the same thing as permission to keep expanding what the session can do.
The second failure is blast-radius growth. A valid session can become a reusable trust container, which makes it easy for an agent to move from a narrow query into bulk retrieval, data modification, or downstream export without a fresh decision. A stronger pattern is to require the control to evaluate each meaningful action, as described in MCP Security Guide, where token passthrough, confused-deputy risk, and gateway enforcement are treated as design problems rather than session trivia.
The third failure is loss of policy granularity. Session-start-only approval cannot distinguish between actions with different sensitivity levels, so it cannot express “read this resource” but not “enumerate everything related to it” or “draft a response” but not “publish or export it.” For that reason, AI Agent Authorisation Guide is useful when you need task-scoped access, per-action policy decisions, and human approval gates around higher-impact calls.
What practitioners should enforce instead
The right unit of control is the individual tool call or a clearly bounded action bundle, not the session alone. Where the action changes sensitivity, data scope, or side effects, the system should re-authorise or re-evaluate the request. That is how you preserve least privilege in delegated execution, rather than converting a session into standing privilege by accident.
When designing the policy, start by classifying which tools are read-only, which can mutate state, and which can reveal or export sensitive results. Then decide which of those categories can share a decision and which must force a new one. If the agent can reach multiple systems, align the check with the destination and the data sensitivity, not just with the identity that opened the session. The Authorisation Models Guide is useful here because it separates coarse role assignment from finer policy-based decisions.
Also verify that the policy engine is evaluating the actual action context, including target resource, tool identity, and requested scope. If a design only logs session establishment but not later authorisation decisions, it will miss the point at which trust expands. That is the common mistake: treating authentication or session creation as if it were equivalent to ongoing authorisation.
Risk and Threat Considerations
Session-start-only checks create a confused-deputy style exposure, because the agent can keep acting under a trust relationship that was granted for a narrower purpose. The risk is not just overreach, but also poor detectability, since later calls may look legitimate unless the system records and evaluates each action boundary.
Failure mechanism: The control validates the beginning of the session but does not re-check the purpose, destination, or sensitivity of subsequent tool invocations, so the session can be reused for broader operations than were originally intended.
Impact: Attackers or overreaching agents can expand from an approved starting point into unauthorized reads, writes, or exports, increasing data exposure and making privilege misuse harder to contain.
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 | Session-start-only authorisation enables an agent to exceed its intended privileges over time. |
| Recommendation — Enforce per-action authorisation for agent tool calls and bound delegated privileges tightly. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Later tool calls need separate enforcement when the action scope changes within a session. |
| IA-5 — Authenticator Management | Session reuse often depends on long-lived credentials or tokens that outlast the original intent. | |
| Recommendation — Apply access decisions at each meaningful tool invocation, not only at session start. Rotate and constrain credentials so session trust cannot be reused indefinitely. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-01 — Identity and Access Management | Zero trust requires continuous verification of access, not a one-time session grant. |
| Recommendation — Re-verify access context as actions change, especially for delegated tool use. | ||
| OWASP ASVS | V8 — Authorization | The problem is a missing authorisation decision at each sensitive action boundary. |
| Recommendation — Require explicit authorization checks whenever a request changes scope or side effects. | ||
Practitioner Guidance
What to verify: Confirm that every tool call with meaningful security impact has an authorisation decision point, or an explicit policy rule that groups only truly equivalent actions. If the only check is at login or session creation, the control is already too coarse for delegated execution.
Decision rule: If the next action can change data, broaden scope, or reach a different system, treat it as a fresh authorisation event unless you can prove the original approval already covered that exact effect.
Practitioner takeaway: MCP authorisation should follow action boundaries, not session boundaries, because delegated systems fail when trust is reusable but intent is not.