Because agent decisions are context-dependent and can change from one action to the next. One-time consent cannot capture what the agent is trying to do right now, for how long, and against which resource, so the control must evaluate each request at execution time.
Why one-time consent breaks down for MCP agents
One-time consent works for a single, bounded decision. MCP agents do not behave that way. They can change intent, tool choice, target resource, or scope from one step to the next, so the control has to evaluate each request at the moment it is executed rather than assuming the original approval still fits.
That runtime check is what keeps the decision aligned to the current action, current context, and current authority boundary. It also prevents an approval for one task from becoming a blanket allowance for later actions that were never part of the original user intent.
What runtime authorisation evaluates that static consent cannot
runtime authorisation asks whether this specific action is allowed now, against this resource, with this audience, and under this policy. That is a materially different question from “was consent given at some earlier point?” It matters because an agent may chain multiple operations, call different tools, or encounter new data mid-flow, and each step can change the risk profile.
In practice, runtime checks are the place where least privilege becomes enforceable. A policy engine can bind the decision to the exact resource, scope, and duration of the request, instead of relying on a broad one-time grant that the agent may continue to use after the context has shifted. That is why externalised authorisation is central to agent control, especially in MCP flows where tool access and token handling are part of the security boundary.
Runtime authorisation also helps distinguish user intent from agent autonomy. The user may approve the task, but the agent still needs a fresh decision for each action that could expose data, spend money, modify state, or invoke a privileged tool. The control is therefore not just about trust, it is about verifying that the current action still matches the permitted intent.
Where this becomes a security boundary, not a UX detail
Without per-action authorisation, MCP agents can overreach in ways that are hard to spot after the fact. A request that started as harmless retrieval can become write access, cross-resource access, or a wider tool invocation path if the agent is allowed to reuse earlier consent without re-evaluating scope.
That is the security reason runtime checks matter: they reduce the blast radius of a mistaken, manipulated, or overbroad agent decision. They also support revocation and short-lived access, so a previously valid decision does not remain effective after the task, context, or trust assumption has changed. For MCP-specific guidance on this control boundary, see MCP Security Guide and the MCP authorization specification at Model Context Protocol: Authorization specification.
Runtime authorisation also aligns with how attacker abuse tends to happen in agentic systems. If an attacker can influence prompts, tools, or intermediate context, a one-time approval can be stretched into unintended actions unless each execution is checked against current policy. That is why agent authorisation must be paired with strong identity and scope handling, as described in AI Agent Authorisation Guide and the broader Authorisation Models Guide.
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 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP agents need per-action checks to stop privilege from exceeding current intent. |
| ASI02 — Tool Misuse | Runtime decisions must gate each tool call because agent context can shift between actions. | |
| ASI01 — Agent Goal Hijack | Execution-time checks help stop a manipulated agent from using stale consent for new goals. | |
| Recommendation — Enforce per-action authorisation to prevent agent privilege from exceeding the approved task. Gate every tool invocation with a fresh policy decision tied to the current context. Re-evaluate authorisation whenever the agent's goal or action path changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | One-time consent can leave agents with broader access than the current task needs. |
| NHI-07 — Long-Lived Secrets | Runtime authorisation pairs well with short-lived access instead of durable reuse of prior approval. | |
| Recommendation — Reduce agent access to the minimum scope needed for each authorised action. Prefer short-lived, task-scoped access over reusable standing permissions. | ||
Practitioner Guidance
What to prioritise: Treat the approval moment and the execution moment as different controls. The approval can express user intent, but the enforcement point must decide whether the current action still matches that intent at the moment the agent acts.
What to verify: Confirm that each request is evaluated with resource, scope, duration, and tool context, not just with a previously issued token or a general user allowance. If those fields are not part of the decision, the control is probably too weak for autonomous execution.
Common mistake: Teams often assume “consented once” means “safe for the whole workflow.” For agents, that shortcut creates hidden privilege accumulation, especially when the agent can move across tools or resources without another policy check.
What good looks like: The agent can proceed only when the runtime policy says the current action is allowed, and the decision can be logged, reviewed, and revoked independently of the original task approval.
Practitioner takeaway: For MCP agents, consent should authorise participation, but runtime authorisation must govern every consequential action, because the security question changes with the context.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org