Because the risk is in the invocation context, not just the caller’s identity. A model can only act on tools it can see, and the actual arguments may make a permitted action unsafe or out of scope. Request-time policy lets the system judge the caller, the tool and the input together before execution.
Why request-time authorization matters for MCP tools
Request-time authorization exists because an AI agent is not making a simple yes or no call based only on who it is. The control has to evaluate the current tool, the current context and the current arguments together. That matters when a tool call is technically valid but operationally unsafe, overbroad, or outside the intended scope of the agent’s delegated authority.
An agent can only act through the tools it can discover and invoke, so the authorization point has to sit close to execution. If policy is checked only at login or only at session start, the system can miss scope changes, risky inputs, or a tool that becomes dangerous only with certain parameters. Request-time policy keeps the decision tied to the exact action about to happen.
This is especially important for MCP because the protocol is designed around tool discovery and invocation. The security question is not merely “is the caller known?”, it is “is this caller allowed to use this tool for this purpose, right now, with these arguments?” That is why the enforcement point needs to understand the request, not just the identity behind it. The MCP authorization specification formalises that model, and MCP Security Guide explains the practical controls around it.
What can go wrong without request-time checks
Without request-time authorization, a tool that looked harmless at onboarding can become risky at runtime. The common failure mode is a permitted identity using a permitted tool in an unintended way, for example by passing arguments that broaden the blast radius, trigger a destructive operation, or access data outside the user’s intent. Static role assignment does not catch that difference.
Another problem is context drift. An AI agent may retain access long after the original user goal has changed, the environment has shifted, or the action is no longer justified. If the authorization decision is not refreshed at the moment of use, the system can treat stale permission as current permission. That is how overbroad access becomes routine rather than exceptional. AI Agent Authorisation Guide and Zero Trust for AI Agents both frame this as a least-privilege and per-action decision problem.
Request-time policy also reduces confused-deputy behaviour. A tool can be legitimate, but the agent may be acting on behalf of a user who should not inherit every capability the agent can reach. Evaluating the tool call at execution time lets the system separate “the agent exists” from “this specific action is allowed.”
How practitioners should implement policy at the action boundary
Request-time authorization works best when it is treated as an enforcement boundary, not a logging event. The policy decision should inspect the caller, the tool, the target resource and the arguments together, then return a decision that the runtime must actually enforce before execution. That means the agent cannot bypass the check by caching a prior allow response or by directly invoking a backend path.
For high-impact tools, a useful pattern is to combine action-scoped access with explicit human approval or step-up review when the request crosses a sensitive boundary. The point is not to stop automation, but to reserve irreversible actions for requests that can be evaluated in context. Agentic AI Security Guide and AI Agent Observability, Audit and Incident Response Guide are useful companions here because they connect authorization, attribution and recovery.
A practical test is whether the policy can answer why this exact call is safe, not just whether the agent is generally trusted. If the answer depends on the current prompt, current target, current data class or current business workflow, then request-time authorization is the right control point. If it cannot express those distinctions, the policy is too coarse for agentic tool use.
Risk and Threat Considerations
The main risk is overbroad tool use, where an agent with legitimate access is induced or permitted to take actions that are technically allowed but operationally unsafe. In MCP environments, that can lead to data exposure, unintended side effects, or abuse of a trusted automation path that was never meant to be unconditional.
Failure mechanism: A prior allow decision is reused for a different tool invocation, or the policy ignores the arguments and target resource that make the call risky. That allows scope creep, confused-deputy behaviour, and abuse of standing privilege at the moment of execution.
Impact: Sensitive actions can execute without a fresh contextual decision, increasing the chance of unauthorized data access, destructive changes, or lateral movement through trusted tools and integrations.
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 API Security Top 10 address 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 | Request-time auth prevents agents from overusing delegated privilege at call time. |
| Recommendation — Enforce per-action authorization checks before any agent tool call executes. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tools are callable functions, so action-level access must be checked on each request. |
| Recommendation — Validate function-level permission for every tool invocation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Per-request policy limits tool use to the minimum needed for the current action. |
| IA-5 — Authenticator Management | Tool access depends on credentials, tokens and their runtime validity. | |
| AU-2 — Event Logging | Request-time decisions are only useful if tool requests and denials are logged. | |
| Recommendation — Scope each agent tool call to the minimum privilege needed. Rotate and constrain credentials used by agent tool sessions. Log each authorization decision and tool invocation for traceability. | ||
| NIST Zero Trust (SP 800-207) | Never Trust, Always Verify | Request-time checks align with continuous verification at the action boundary. |
| Recommendation — Reevaluate trust and policy at each tool request. | ||
| OWASP ASVS | V8 — Authorization | The core issue is whether each action is authorized, not merely authenticated. |
| Recommendation — Require authorization checks for every sensitive tool action. | ||
Practitioner Guidance
What to verify: Check that authorization is evaluated at the exact point of tool invocation and that the runtime cannot execute a tool after a stale allow decision. The control should consider the tool name, target, arguments and acting principal together.
Decision rule: If a tool call can change data, spend money, expose secrets, or cross a trust boundary, require a fresh request-time decision rather than relying on session-level trust. If the call is low impact and fully reversible, the policy can be simpler, but it still should be explicit.
Practitioner takeaway: The safest MCP design is not “trusted agent, trusted tools”, it is “trusted request, trusted context, trusted action”, with a fresh decision for every invocation that can materially change the environment.
Related resources from NHI Mgmt Group
- How should teams govern AI agents that use MCP?
- Why do AI agents create more IAM risk than ordinary developer tools?
- Why do AI agents need request-time authorization instead of session approval?
- How should security teams design authorization for MCP servers so hidden tools cannot be called by AI agents or scripted clients?