They often treat securitySchemes as a complete control, when it is really just metadata that describes required access. The server still has to validate the token, enforce the declared scope, and fail closed if the caller is missing permission. Without backend checks, tool declarations become documentation instead of enforcement.
Why This Matters for Security Teams
In MCP, securitySchemes are often read as if they were an enforcement layer, but they are only a declaration of what access the tool expects. That distinction matters because tool metadata can be correct while the server still accepts an unvalidated token, ignores scope, or returns data when permission should have failed. OWASP’s OWASP Agentic AI Top 10 frames this as a broader agentic trust problem: the control plane looks explicit, but the runtime still has to prove identity and authorisation.
This is especially important for teams integrating MCP into workflows where AI agents can chain tools, retry actions, and operate with delegated tokens. The declaration helps clients understand what to request, but it does not stop a compromised or over-scoped caller from invoking the tool if the backend is permissive. NHI governance research from The State of Non-Human Identity Security shows how often organisations underestimate where real enforcement must happen, especially when identities are machine-issued and hard to observe. In practice, many security teams discover broken tool authorisation only after an agent has already used the tool successfully, rather than through intentional design review.
How It Works in Practice
The right model is to treat securitySchemes as contract metadata, not as proof of security. In an MCP deployment, the client uses the declared scheme to know how to authenticate, but the server must still validate the presented credential, bind it to the right workload or user, and enforce the exact scope needed for the requested operation. That runtime decision should happen on every request, not just at connection time. Current guidance from the MCP and agentic security community aligns with this, but there is no universal standard for every deployment pattern yet.
Practically, this means three checks must all succeed: the token is authentic, the scope matches the tool action, and the server fails closed when any required claim is absent. If the tool supports high-risk operations, teams should prefer short-lived, context-bound credentials and policy checks that can examine request content, caller identity, tenant, environment, and data sensitivity. The emerging pattern is closer to runtime authorisation than classic static IAM.
- Validate tokens server-side, never trust the client’s declaration alone.
- Map each tool action to a minimal scope or permission and reject extras.
- Use workload identity and short TTL credentials for agent-driven calls.
- Log both the declared scheme and the actual authorisation decision for auditability.
That approach matches the direction of OWASP Top 10 for Agentic Applications 2026 and NHI-focused guidance from OWASP Agentic Applications Top 10. These controls tend to break down when mcp server proxy requests through shared service accounts because the server can no longer distinguish one agent’s intent from another’s.
Common Variations and Edge Cases
Tighter enforcement often increases integration overhead, requiring organisations to balance developer convenience against actual containment. That tradeoff shows up quickly in MCP ecosystems where multiple clients, plugins, or agents share the same tool endpoint. Best practice is evolving, but current guidance suggests that shared endpoints need explicit backend policy, not just a common security scheme, because the scheme alone cannot express per-call intent or contextual exceptions.
One common edge case is delegated access: a user authorises an agent once, then assumes the agent will remain bounded by that consent forever. Another is tool fan-out, where one MCP call triggers downstream systems that were never represented in the original declaration. In both cases, the server should re-evaluate access at runtime and keep credentials ephemeral. NHI programmes also need to distinguish between documentation and control ownership, a pattern reinforced by the operational findings in AI Agents: The New Attack Surface report.
Security teams should treat any environment with long-lived tokens, shared service identities, or loosely scoped broker services as high-risk for false confidence. Those environments are where securitySchemes most often look “implemented” while enforcement remains partial.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 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 | Explains why agent tools need runtime authorization, not metadata-only trust. |
| CSA MAESTRO | IAM | Covers identity and access controls for agentic workflows and tool invocation. |
| NIST AI RMF | GOVERN | Supports governance for trustworthy AI systems using auditable access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses improper trust in non-human identity credentials and access boundaries. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Requires continuous verification instead of trusting declared access alone. |
Validate each MCP tool call at runtime and reject access when scope or intent does not match.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
