MCP changes the model because agents discover tools dynamically and may request capabilities after initial login. Traditional consent assumes a fixed set of scopes chosen up front by a human. In MCP, authorization has to handle per-tool decisions, dynamic consent, and identities that travel with each tool call, or the server ends up granting broader access than intended.
Why This Matters for Security Teams
MCP servers change authorization from a one-time OAuth consent screen into an ongoing trust decision made at tool discovery and tool use. That matters because autonomous agents do not behave like a single human session with stable intent. They can chain tools, retry failed actions, and request new capabilities after the initial login, which means fixed scopes often under-describe the real risk. Current guidance suggests this is where traditional consent models become too coarse for agentic workloads.
The problem is not OAuth itself. The problem is assuming that a human-approved scope list can safely govern an agent that may discover new tools mid-task. NIST’s NIST Cybersecurity Framework 2.0 emphasizes adaptable governance, while NHIMG research on OWASP NHI Top 10 shows how identity and authorization controls fail when workloads can act outside the original intent. In the wild, teams usually discover the weakness only after an agent has already asked for broader access than the operator expected.
How It Works in Practice
Traditional OAuth works best when a user selects an app, reviews a known scope set, and grants access for a defined purpose. MCP breaks that assumption because the agent can discover new servers, new tools, and new actions after the session begins. That means authorization must move closer to runtime, with decisions based on the specific tool, the requested operation, the agent’s identity, and the current context.
In practice, security teams should treat MCP tool use as a sequence of narrowly evaluated requests, not a blanket delegated session. The emerging pattern is:
- Use workload identity to prove what the agent is before any tool call is authorized.
- Issue short-lived, just-in-time credentials rather than long-lived static secrets.
- Evaluate policy at request time, using context such as tool name, data sensitivity, and task state.
- Separate user consent for the agent’s mission from authorization for each downstream capability.
- Revoke or down-scope access automatically when the task completes or changes.
This maps closely to the broader agent security direction described in AI Agents: The New Attack Surface report, where NHIMG notes that only 52% of companies can track and audit the data their AI agents access. That blind spot becomes more dangerous with MCP because the server may not only expose data, but also amplify what an agent can do with it. Best practice is evolving toward policy-as-code, with real-time decisions enforced by systems like OPA or Cedar rather than pre-defined scope bundles alone.
These controls tend to break down when MCP servers are integrated into legacy OAuth gateways that only understand static scopes, because the gateway cannot see the full tool chain or the agent’s next move.
Common Variations and Edge Cases
Tighter per-tool authorization often increases operational overhead, requiring organisations to balance better containment against more policy maintenance and user friction. That tradeoff is real, especially in environments where agents must move quickly across many tools and data sources.
There is no universal standard for this yet. Some teams keep OAuth for initial user authentication and use a second layer for tool authorization, while others experiment with intent-based checks tied to the specific action the agent is trying to perform. The right answer depends on whether the MCP server is handling read-only retrieval, sensitive write actions, or privileged administrative tasks. Guidance suggests the risk rises sharply when the server can invoke downstream systems, not just return context.
Edge cases matter. A low-risk documentation tool may justify broader access than a finance or production-change tool, but that exception should be explicit and logged. NHIMG’s The State of MCP Server Security 2025 shows how common configuration weaknesses already are, which means authorization logic cannot be treated as a separate problem from secret handling and server hardening. In practice, the most dangerous failures happen when a server combines broad OAuth consent, hard-coded credentials, and weak tool scoping in the same deployment.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Dynamic tool use and overbroad agent authorization are core agentic risks. |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP servers often rely on secrets and delegated access that must be tightly scoped. |
| CSA MAESTRO | MAESTRO addresses governance patterns for autonomous agent access and tool control. | |
| NIST AI RMF | GOVERN | AI RMF governance is needed to assign accountability for agent-driven access decisions. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires continuous verification rather than trust based on initial login. |
Verify identity and context for every MCP tool request, not just at session start.
