Why does MCP scope-based step-up create risk for long-running AI agents?

Why MCP scope-based step-up can outlast the human who approved it

MCP scope-based step-up creates a subtle trust gap because it authorises capability, not continued supervision. For long-running AI agents, that distinction matters: the agent can keep operating across token refreshes, task resumes, and delayed tool calls while the original human context becomes stale. A permission grant that was reasonable at the start of a workflow can become unsafe later if the agent is still able to act without a fresh human decision. The OWASP OWASP Top 10 for Agentic Applications 2026 treats agent autonomy and delegated action as a distinct control problem, not just an authentication problem.

The security issue is not that scopes are useless. It is that scopes can remain valid after the operational conditions that justified them have changed. In destructive or irreversible workflows, that creates a time-of-check to time-of-use gap across a much longer window than many teams expect. In practice, many security teams discover this only after an agent has already continued executing beyond the moment a human intended to remain in the loop.

How long-running agents turn scope into an ageing authorisation decision

Step-up usually answers, "may this caller do this action now?" Long-running agents ask a different question: "who is accountable for the next action after the session has drifted?" If the answer remains embedded in a scope token or cached approval, the control can become weaker over time because the agent may continue to act while the original context, intent, or business condition has changed. That is especially important where the agent can chain tool calls, queue work, or resume after interruption.

Good practice is to treat the original approval as a bounded delegation, not a standing licence. The practical checks are straightforward:

• Does the scope expire quickly enough for the workflow risk?
• Can the agent re-use an old approval after a pause, retry, or refresh?
• Is a fresh human confirmation required before a destructive or externally visible action?
• Is the agent’s tool access reduced when the task enters a higher-consequence phase?

This is where MCP design choices matter. If the control plane assumes the session is still "the same request" long after the human has stopped watching, the system may preserve authorisation longer than the organisation would permit if the action were being reviewed manually. The result is not just over-permission. It is stale permission applied to a moving task context, which is harder to see in audit trails and easier to misuse through retries, delayed execution, or queued automation. The NIST NIST AI Risk Management Framework is useful here because it pushes teams to manage AI action risk across the full lifecycle, not just at initial authorisation.

Where teams most often get this wrong is assuming token freshness and decision freshness are the same thing. They are not, and once that separation exists, the agent can still act under a valid scope even though the human context has effectively gone stale.

When step-up is not enough, and where the control boundary shifts

Tighter approval controls often increase friction, so organisations have to balance safety against workflow continuity. The trade-off is most visible in long-lived agents, background jobs, and exception paths, where a single approval can cover more time and more tool use than the user expected. That tension is accepted in the industry, but there is no consensus that a single scope grant should cover all later actions in a multi-stage agentic workflow.

Two edge cases matter most. First, retry logic can silently extend the useful life of an old approval, even when the human never intended a second attempt. Second, delegated actions that look low risk early in the task can become high risk later once the agent has gathered data, prepared outputs, or opened a side effect path. In both cases, the issue is not the existence of scopes; it is the assumption that the original approval remains valid for every later phase. A useful comparator is the OWASP OWASP Non-Human Identity Top 10, which highlights how machine-held credentials and long-lived access create governance problems when ownership and intent are no longer actively enforced.

For that reason, step-up should be treated as a checkpoint in a broader delegation model, not as the final word on trust. Once an agent can outlive the moment of approval, the control boundary has shifted from "who signed in" to "who is still allowed to continue." Where that boundary is unclear, scope-based step-up breaks down.

Risk and Threat Considerations

Scope-based step-up creates a stale-authorisation risk for long-running agents because permission can survive longer than the human oversight that justified it. In agentic workflows, that allows an unattended process to keep using legitimate access after the operator has stopped monitoring, which is a governance and safety issue even when no attacker is present.

Failure mechanism: the agent retains a valid session or cached scope across refresh cycles, retries, or queued tool calls, so later actions inherit earlier approval even though the task context has changed. The same mechanism can be abused if an adversary can delay, hijack, or trigger deferred execution while the original approval remains active.

Impact: destructive actions can proceed without fresh human intent, audit trails can understate how stale the decision was, and a compromised or misdirected agent can use legitimate permissions to produce irreversible side effects.

Practitioner Guidance

What to prioritise: treat any workflow that can cross a time boundary, retry boundary, or human handoff as a higher-risk delegation case. The key question is not whether the scope was valid at sign-in, but whether it is still valid for the next action.

Decision rule: if the agent can make an irreversible change, send data externally, or continue after a pause, require a fresh human decision for that phase rather than relying on the original scope alone. If the task is reversible and low impact, shorter-lived scopes may be sufficient.

What to verify: confirm that refresh, resume, and retry paths do not silently inherit the same authority as the initial approval. Teams should be able to show when the last meaningful human decision occurred, what action it covered, and what would force re-approval.

Practitioner takeaway: long-running agents should be governed by decision freshness, not just token freshness, because the most dangerous failure is a valid permission applied after the human context has expired.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do AI agents create a different access-risk profile than traditional applications?