MCP Step-Up Authorisation allows agents to request elevated permissions only at the moment a sensitive operation requires them rather than holding broad permissions throughout their session. The agent starts with minimal permissions and requests additional scopes only when a specific operation requires them. Those elevated permissions are granted for the duration of the sensitive operation and then automatically revoked.
Why This Matters for Security Teams
MCP Step-Up Authorisation matters because agents do not behave like static service accounts. They execute goals, chain tools, and can cross from routine actions into sensitive operations without warning. If an agent holds broad access for the whole session, every compromise, prompt injection, or mis-routed task becomes a privilege problem. That is why least privilege for agents must be decided at the moment of action, not assumed at login. Guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime control, accountability, and context-aware governance rather than one-time trust.
NHIMG research shows why this is not theoretical: the OWASP NHI Top 10 highlights how agentic systems expand the attack surface when identity and authorisation are too coarse. The practical issue is not whether an agent needs access, but whether it should keep that access after a single sensitive step is complete. In practice, many security teams encounter over-privilege only after an agent has already used it.
How It Works in Practice
MCP Step-Up Authorisation is best understood as intent-based authorisation for autonomous workloads. The agent begins with a minimal baseline, usually a workload identity plus tightly scoped default permissions. When it reaches a sensitive action, such as reading a protected data set, issuing a deployment, or modifying infrastructure, the MCP flow requests an elevation check before the tool call proceeds. If approved, the additional scope is issued as a Zero Trust Architecture style decision, time-boxed and context-specific rather than session-wide.
Practitioners should treat this as a chain of controls, not a single feature:
- Use workload identity to prove what the agent is before authorisation begins.
- Issue just-in-time credentials or tokens only for the task that needs them.
- Bind elevation to policy conditions such as task type, data sensitivity, and environment.
- Revoke the elevated scope immediately after the operation completes.
This model aligns well with the risk patterns described in NHIMG coverage of agentic security, including the AI LLM hijack breach and Ultimate Guide to NHIs — Key Challenges and Risks, where scope drift and credential exposure are central failure modes. The OWASP Non-Human Identity Top 10 is also useful here because it reinforces that static secrets and standing access are the wrong default for non-human actors. These controls tend to break down in legacy systems where tool APIs cannot evaluate runtime policy and where long-lived service tokens are hard-coded into orchestration workflows.
Common Variations and Edge Cases
Tighter step-up controls often increase latency and operational overhead, so organisations have to balance friction against the risk of runaway privilege. That tradeoff is real, especially in high-volume agent pipelines where dozens of tool calls may occur per minute. Current guidance suggests reserving step-up for actions that are high impact, externally visible, or hard to reverse, while leaving low-risk read-only actions on baseline access. There is no universal standard for this yet.
There are also important edge cases. Some teams try to approximate step-up with RBAC alone, but RBAC is usually too coarse for agents because the same agent may need different permissions within the same minute depending on task state. Others rely on PAM without tying it to the agent’s runtime intent, which can still leave broad elevation available longer than necessary. For autonomous systems, the better pattern is ephemeral secrets, short TTLs, and policy evaluation at request time, which is why the Ultimate Guide to NHIs — What are Non-Human Identities and Analysis of Claude Code Security remain relevant references. The emerging best practice is to treat MCP authorisation as a live control plane, not a permissioning setup step.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic systems need runtime controls for tool use and privilege escalation. |
| CSA MAESTRO | TRUST | MAESTRO covers runtime trust and policy decisions for autonomous agents. |
| NIST AI RMF | GOVERN | AI RMF governance supports accountability for dynamic agent authorisation. |
Require step-up checks before sensitive tool calls and revoke elevation immediately after execution.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
