FastMCP exposes an MCP authorization gap in production servers

At a glance

What this is: This is an analysis of how FastMCP can surface an MCP authorisation gap when tool exposure is not separated from policy enforcement.

Why it matters: It matters because IAM teams need to treat MCP tool access like governed application access, not like automatic API security, especially when agents act on behalf of users.

Context

Model Context Protocol servers expose tools and resources to connected clients, so the governance problem is not just transport or authentication. The core issue is whether each tool call is evaluated against the caller's permissions before execution, especially when an AI agent is acting on a user's behalf.

FastMCP reduces the friction of building production MCP servers, but that convenience can obscure a structural access-control gap. If authorization lives inside scattered server logic, every new tool, prompt, or resource expands the chance that policy and exposure drift apart.

For IAM and platform teams, the question is whether MCP is being treated as a governed access surface or as a developer convenience layer. The distinction matters because the security model has to follow the actor and the action, not just the protocol.

Key questions

Q: What breaks when FastMCP exposes every tool to every connected user?

A: Least-privilege design breaks first. If tool listing and tool execution are not separately authorised, any connected client can discover and potentially invoke capabilities that should be restricted by role, context, or resource sensitivity. In practice, that turns an MCP server into a broad permission surface and makes sensitive actions available far beyond their intended audience.

Q: Why do MCP servers need policy-based authorisation instead of hardcoded checks?

A: Because hardcoded checks couple security decisions to application code and make every new tool a code change. Policy-based authorisation lets teams update permissions independently of releases, audit rules centrally, and keep access decisions consistent across tools, prompts, and resources. That is the only scalable way to keep MCP growth aligned with governance.

Q: What are the signs that MCP observability is failing in production?

A: The clearest signs are blind spots and unanswerable questions. Teams cannot say which MCP servers are live, which tools were called, what data moved through them, or which user initiated the action. Investigation stalls because logs do not link related events across servers, and operational work becomes guesswork rather than evidence-based monitoring.

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Technical breakdown

Why MCP tool enumeration creates an authorisation problem

MCP servers advertise available tools, prompts, and resources to clients before any actual use occurs. That discovery model is useful for agent interoperability, but it also means a naive server can reveal and expose capabilities that should only exist for certain roles. In practice, the server becomes an access broker, not just a transport endpoint. If the decision to allow a tool call is not separated from the application code that defines the tool, every new capability inherits the risk of default exposure. The technical issue is not that MCP is unsafe by design, but that its publish-and-call pattern requires explicit policy evaluation at runtime.

Practical implication: Treat tool listing and tool execution as distinct control points and enforce a decision before the call is allowed.

How policy-driven access control changes FastMCP enforcement

Policy-driven authorization moves the decision outside the server implementation and into a central policy engine. In this pattern, the MCP server declares tools and resources, while the middleware asks a policy decision point whether the current principal may list or call a specific action. That decoupling is important because it lets identity attributes, roles, and request context drive the decision without hardcoding if/else logic into server code. It also makes authorisation auditable and testable as configuration rather than application logic. For production, the main architectural benefit is that adding a tool does not automatically expand access, because exposure is constrained by policy rather than by code paths.

Practical implication: Use external policy decisions for tool and resource access so new MCP capabilities do not bypass review.

Why agent-on-behalf-of-user access must inherit user permissions

When an AI agent invokes MCP tools on behalf of a user, it is not enough to authenticate the agent or the session. The agent's effective permissions must be bounded by the user's permissions, otherwise the agent becomes a privilege amplifier. This is especially important in MCP because tools can perform sensitive actions, not just read data. If the policy layer is missing, a low-privilege user can route a high-risk action through an agent that appears to be a normal application call. The security model therefore has to preserve user context through the whole request path, from identity construction to policy evaluation to tool execution.

Practical implication: Bind every agent request to the originating user context and evaluate tool access at that same privilege level.

Threat narrative

Attacker objective: The objective is to gain access to MCP tools and resources beyond the user's intended permissions and use them to perform sensitive actions.

1. Entry occurs when a client connects to an MCP server that exposes tools and resources as part of the protocol discovery flow.
2. Credential or permission misuse follows when the server does not evaluate whether the caller should list or call a specific tool.
3. Escalation happens when a low-privilege user can trigger sensitive tool actions through an agent or through over-broad server defaults.
4. Impact is the unauthorised execution of high-risk operations such as data deletion, sensitive reads, or other privileged workflow actions.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP access control is now an identity problem, not just an application design problem. The article shows that a production FastMCP server can expose every tool by default unless authorization is explicitly separated from server logic. That means the real governance question is who can invoke which tool, resource, or prompt under what context, not whether the framework makes development easier. Practitioners should treat MCP as a governed access surface from the first deployment, not after the first incident.

Hardcoded if/else authorization is a governance anti-pattern for MCP. When access rules live inside server code, every new tool becomes a policy change, a regression risk, and a deployment dependency. That is brittle because identity policy should outlive application release cycles and remain auditable as the environment changes. For identity teams, the practical implication is that tool authorisation has to be policy-driven and externally managed, or the control plane collapses into application sprawl.

Policy-driven MCP access aligns better with least privilege than role labels alone. The article's examples show that simple user versus admin splits are not enough once tools and prompts can carry different risk levels. Attribute-aware decisions are more defensible because the relevant question is not just who the caller is, but what they are trying to do and in which context. That pushes MCP governance toward dynamic entitlement checks rather than static role assignment.

Dynamic tool exposure creates an identity blast radius that expands with every new capability. Each additional tool or resource increases the number of actions that must be constrained by policy, and every missing decision widens the blast radius of a compromised or over-permissioned principal. In NHI terms, this is the same structural problem that appears when service accounts accumulate scope without lifecycle control. Practitioners should assume MCP tool inventories will grow faster than manual governance can keep up.

FastMCP exposes a broader control-plane shift in AI application security. The article points toward a market where frameworks accelerate agent and tool development faster than security teams can embed access governance by default. That validates the need for identity-aware middleware, policy decision points, and auditable enforcement outside application code. The implication for practitioners is clear: secure-by-construction claims need to be tested against runtime authorisation, not only against developer ergonomics.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

MCP deployments should now be assessed as policy-bearing identity surfaces, not just application interfaces. If a server can enumerate tools without a permission check, then access governance is already happening too late in the request path.

Identity blast radius: every new MCP tool expands the amount of damage a mis-scoped principal can cause unless authorisation is externalised and testable. That is the governance shift teams need to plan for as agentic and tool-based applications move into production.

For practitioners

• Separate tool definition from tool authorisation Keep MCP server code focused on capability exposure and enforce access decisions in a policy layer that evaluates each list and call action independently.
• Bind agent requests to user permissions Make the agent inherit the originating user's identity, role, and contextual attributes so a low-privilege request cannot trigger a high-privilege tool call.
• Replace hardcoded checks with external policies Move MCP access rules out of if/else branches and into declarative policies that can be updated, audited, and tested without a full redeployment.
• Review every tool for privilege impact Classify each new tool, prompt, and resource by the damage it could do if exposed broadly, then require explicit policy coverage before production use.

Key takeaways

• FastMCP makes MCP server development easier, but that convenience can mask a serious access-control gap when every tool is exposed by default.
• The article's core governance point is that MCP authorisation has to be policy-driven and separate from application code if teams want predictable least-privilege enforcement.
• For practitioners, the control that matters most is runtime authorisation at tool-calls, not developer confidence in the framework or the agent.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Policy Driven Authorization: A policy driven authorization model makes access decisions from centrally defined rules rather than hard coded application logic. It lets teams express who can do what, under which conditions, and across changing business contexts. This approach is designed to be flexible enough for new use cases without forcing application rewrites.
• Delegated agent access: A pattern where an AI agent performs actions on behalf of a human user and should therefore inherit that user's permissions. The governance challenge is preventing the agent from becoming a privilege amplifier or bypassing user-scoped controls.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.