FastMCP exposes an MCP authorization gap in production servers

At a glance

What this is: This is a Cerbos guide to building FastMCP servers and the security gap that appears when MCP tools are exposed without fine-grained authorization.

Why it matters: It matters because MCP turns AI-connected functionality into an identity and authorization problem, and IAM teams need controls that follow the user, the tool, and the request context.

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.

👉 Read Cerbos's guide to securing FastMCP servers with policy-based authorization

Context

MCP server security is the problem space here, not just Python ergonomics. FastMCP lowers the barrier to publishing tools and resources into an LLM context, but that convenience also makes access scoping the primary control question for production deployments. The real issue is whether tool execution is governed with the same discipline as other identity-bound application paths, including NHI permissions and agent-mediated access.

When an MCP server exposes tools without policy enforcement, the server effectively advertises capability before it proves entitlement. That is an identity governance failure, because the caller may be a human, an API-driven workload, or an AI agent acting on behalf of a user. The security model has to decide who can invoke which tool, under what attributes, and with what auditability.

Key questions

Q: How should security teams implement authorization for MCP servers?

A: Use policy-driven authorization in front of tool execution, not inline if/else logic inside the server. The policy layer should evaluate the caller’s identity, role, and request context before allowing a tool, resource, or prompt action. That gives teams a reviewable control point and reduces the risk of exposing every tool to every user.

Q: What breaks when MCP tools are exposed without fine-grained access control?

A: Unprivileged users or agents can discover and invoke tools they should never reach, including actions that delete data or trigger sensitive workflows. In practice, this turns a convenient protocol into an authorization bypass problem. The server still works technically, but the organisation loses the ability to enforce entitlement at the point of use.

Q: How do you know if MCP authorization is actually working?

A: You should be able to prove that tool listing, tool calling, and resource access produce different outcomes for different principals and attributes. If every user sees the same capabilities, the policy is not doing real work. The clearest signal is whether sensitive tools remain invisible or unusable outside approved roles and contexts.

Q: Who should own MCP access governance in an enterprise?

A: Ownership should sit with identity and security teams, not only application developers, because MCP connects user intent to privileged execution. The governing team needs authority over policy design, review cadence, and audit evidence. That keeps MCP aligned with enterprise authorization standards rather than ad hoc server behaviour.

Technical breakdown

How MCP tool exposure creates an authorization boundary

MCP separates the specification from the server implementation. The protocol lets a server publish tools, prompts, and resources to a connected client, but the server must still decide whether a caller may list or invoke them. In a default implementation, enumeration and execution can be too broad because the protocol itself does not provide business-policy logic. FastMCP simplifies server creation, but that also means authorization must be added deliberately rather than assumed. The security boundary is therefore not the tool definition itself, but the decision point that sits in front of tool execution.

Practical implication: treat every tool as privileged until policy proves the caller is entitled to use it.

Why hardcoded if/else authorization fails in MCP servers

The article describes a common anti-pattern: embedding role checks and business logic directly inside server code. That approach is brittle because permissions become tied to application releases, and every new tool or rule change requires code edits. It also makes audit and review harder, because authorization intent is scattered across functions instead of expressed as policy. For production MCP, this creates an operational gap between what the server can do and what the organisation is willing to allow. Policy-driven authorization closes that gap by making decisions explicit and testable.

Practical implication: move access logic out of tool handlers and into centrally managed policy.

Policy-based access control for MCP resources and tools

Cerbos-fastmcp uses a middleware pattern to intercept requests and query a policy decision point before the tool call proceeds. That means the MCP server can define all available capabilities, while policy determines which ones are visible or callable for a given principal, role, or attribute set. This is closer to ABAC than simple role-only gating, because the request context can shape the decision. The operational value is that authorization becomes a separate control plane, which is easier to test, update, and scale than inline code logic.

Practical implication: use policy-driven middleware so access decisions can change without redeploying the server.

Threat narrative

Attacker objective: The attacker objective is to convert broad tool exposure into unauthorized action, data loss, or credential-assisted lateral access through the MCP server.

1. Entry occurs when a connected client reaches an MCP server that advertises tools and resources without sufficient access scoping.
2. Escalation happens when an unprivileged user or agent can invoke sensitive tools because the server does not enforce per-tool entitlement checks.
3. Impact follows when exposed tools can delete data, trigger sensitive operations, or bypass the tighter controls normally wrapped around traditional APIs.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 server authorization is now an identity problem, not just an application design choice. FastMCP makes tool publication easy, but the article shows that the real control point is entitlement enforcement at the request boundary. Once AI-connected tools are exposed, IAM teams must treat them as governed capabilities rather than harmless developer conveniences. The implication is that MCP belongs in the same governance conversation as service accounts, API keys, and workload identity.

Policy-based middleware is the right architectural direction because it separates capability from permission. The article’s central strength is that it decouples tool definition from access decisioning, which is exactly what hardcoded checks fail to do at scale. That separation improves auditability, testing, and change management without tying every rule to a deployment cycle. Practitioners should see this as a control-plane pattern for MCP, not a framework-specific implementation detail.

Role checks alone are too coarse for production MCP servers. The example policy already hints at a deeper truth: access decisions often need roles, attributes, and request context to be useful. A simple USER versus ADMIN split does not capture team membership, environment, or tool sensitivity well enough for real governance. The implication is that MCP authorization needs finer-grained policy expressions than many application teams are accustomed to using.

FastMCP extends the same governance pressure that AI agents and NHIs already place on enterprise identity. The control failure is not unique to MCP, but MCP makes it visible because tool access sits directly in the path between intent and execution. That means the same discipline used for NHI least privilege, access review, and policy lifecycle must now extend to AI-connected server surfaces. Practitioners should align MCP governance with broader identity and authorization governance rather than managing it as a standalone developer pattern.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For adjacent control design, see OWASP Agentic Applications Top 10 for the governance risks that appear when tools, context, and execution converge.

What this signals

Runtime tool governance will become a standard requirement for AI-connected services. As MCP adoption spreads, teams will need policy controls that operate at the tool boundary, not just at the login boundary. The governance gap is structural because authorization has to understand who is calling, what they are calling, and whether the call should be visible at all.

With 80% of organisations reporting AI agents acting beyond intended scope in AI Agents: The New Attack Surface report, the warning for practitioners is clear: protocol simplicity does not remove entitlement complexity. FastMCP makes server creation faster, but fast development cannot substitute for access modelling, policy review, and auditable enforcement.

MCP entitlement debt: the longer teams rely on inline authorization logic, the harder it becomes to prove which tools are actually protected. That matters because AI agents, workloads, and delegated users all converge on the same server surface. Practitioners should expect MCP authorization to be reviewed alongside broader NHI and agent governance controls.

For practitioners

• Separate tool definition from authorization policy Keep MCP tool logic free of inline access rules and enforce entitlements in a dedicated policy layer so decisions can be reviewed, tested, and changed without code rewrites.
• Scope every MCP tool by role and attributes Apply different rules to listing, calling, and sensitive operations, then use principal attributes such as department or team ownership to narrow access beyond broad roles.
• Test authorization before production rollout Run unit and integration tests against the policy model so hidden access paths, over-permissive rules, and tool enumeration issues are caught before deployment.
• Treat MCP servers as privileged identity surfaces Bring MCP into the same governance process you use for service accounts and workloads, including approvals, change control, and periodic review of tool exposure.

Key takeaways

• FastMCP reduces the effort required to build MCP servers, but it also makes access control the critical security decision.
• The practical risk is not the tool framework itself, but the assumption that broad tool visibility is acceptable without explicit policy enforcement.
• Teams that move authorization into a separate policy layer gain a control model that is easier to test, audit, and adapt as MCP deployments grow.

Key terms

• Model Context Protocol: A standard for connecting language-model applications to tools and data sources in a structured way. MCP defines how clients discover capabilities and how servers expose resources, prompts, and tools, but it does not replace business authorization or identity governance.
• FastMCP: A Python framework that helps developers build MCP servers with less boilerplate and more production-oriented structure. It simplifies server creation, but it still requires separate policy and identity controls if the exposed tools are sensitive.
• Policy-driven authorization: An access-control model where entitlement decisions are made from external policy rather than embedded application code. For MCP, this allows tool visibility and execution to be governed centrally, tested consistently, and updated without changing the server implementation.
• Tool enumeration: The act of listing the capabilities a server exposes before any tool is called. In MCP, enumeration is itself a security-sensitive event because revealing sensitive tools to the wrong principal can create a precursor to misuse or social engineering.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: FastMCP and policy-based authorization for MCP servers. Read the original.