Notifications
Clear all
Topic starter
11/06/2026 10:58 pm
TL;DR: MCP standardises how AI agents connect to tools and data, but leaves authorization decisions to implementers, creating exposure when scopes, tool access, and context-window controls are too loose. The article argues that deterministic permissioning, not stronger authentication alone, is the missing control layer for AI applications.
NHIMG editorial — based on content published by Authzed: MCP security is an authorization problem, not an authentication one
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern MCP tool access in production?
A: Security teams should define tool-level authorization rules, not just authenticate the caller.
Q: Why do MCP deployments increase the risk of data exfiltration?
A: MCP can place sensitive data, untrusted content, and outbound communication in the same workflow.
Q: What do security teams get wrong about MCP authorization?
A: Teams often assume authentication and token scopes are enough.
Practitioner guidance
- Map every MCP tool to an explicit permission decision Inventory which tools, resources, and data classes each server can reach, then define a deterministic allow or deny rule for every call path.
- Separate context ingestion from tool execution rights Limit what data can enter the model context window and independently control which tools the agent may call.
- Move authorization checks to execution time Validate permissions at the moment the tool is invoked, not only at login or session creation.
What's in the full article
Authzed's full article covers the operational detail this post intentionally leaves for the source:
- How the OAuth 2.1 and OpenID Connect pieces fit into MCP server implementation
- The breach timeline and the specific incidents that illustrate prompt injection, tool poisoning, and supply chain exposure
- The architecture discussion around code mode, TypeScript APIs, and low-latency authorization design
- Why the vendor argues deterministic authorization must sit alongside, not inside, AI-based detection
👉 Read Authzed's analysis of MCP authorization gaps and AI security →
MCP authorization gaps: what security teams need to fix now?
Explore further
12/06/2026 7:26 am
MCP security is an authorization design problem disguised as an integration problem. The protocol’s identity mechanics are real, but they stop at proving who connected and which scopes were requested. That leaves the hard decision of what a tool call is allowed to do inside the application and its policy layer. Practitioners should stop treating MCP as a secure transport and start treating it as a permissions architecture that must be deliberately governed.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: How can organisations reduce prompt-injection risk in MCP workflows?
A: They should reduce the amount of sensitive content that can enter the context window, constrain which tools can act on that content, and block unnecessary outbound communication. Prompt injection becomes far less effective when the model cannot both see valuable data and exfiltrate it through a permitted channel.
👉 Read our full editorial: MCP security is an authorization problem, not an authentication one
