Loading
Loading
2938 Members
Join Permit's SlackLet me start with this: adopting MCP in production today is a bit like trying to install a rocket engine on your bicycle. It will take off, just not necessarily in the direction you intended. And if you’re anything like us, you’ll probably end up duct-taping half of it together while searching how to “override OAuth token expiration” at 3 a.m.
But that doesn’t mean it’s not worth it. Model Context Protocol (MCP) introduces a whole new model for building intelligent, agentic systems. It gives AI agents the context they need to reason, decide, and act, not just call APIs. It also introduces a set of security and identity challenges that most systems today simply aren’t designed for.
This guide is about those challenges. Specifically: identity, consent, delegation, and the architectural groundwork needed to secure MCP-based systems.
Let’s clear this up early. MCP is not a smarter API gateway or a prompt formatting spec. It’s a protocol designed to give agents access to contextualized tools—and with that, the capacity to make decisions.
At the center is an MCP server, which streams definitions of tools, capabilities, and resources to agents. Agents connect as clients, receive context, authenticate, and start reasoning about what’s available. They can then choose which tools to use, how to chain them, and what action to take. It’s not deterministic. It’s not scripted. It’s inference-driven behavior based on the context the agent receives.
That’s powerful. But once the agent can choose, deduce, and act, the attack surface expands. And suddenly, identity and control become fundamental—not optional.
One of the most common misunderstandings with MCP today is treating authentication like a standard OAuth handshake. But MCP systems involve multiple parties, multiple flows, and multiple policies, often running concurrently.
There are five distinct layers of authentication and authorization that must be addressed:
When these identities are conflated—or worse, when agents operate without their own identity—you end up with logs that are effectively unreadable. “Something did something” doesn’t help when trying to explain who triggered a transaction or authorized access to sensitive data.
MCP is fundamentally about context. But context in this case isn't metadata—it's executable intent.
When a tool is exposed to an agent via an MCP server, it often includes instructions or prompts as part of the context payload. This means the agent isn’t just calling a function—it’s receiving behavioral influence. It can be told to ignore other tools. It can be encouraged to take a specific path. And this influence can be abused.
There are several risks introduced by this model:
This is the cost of giving agents real reasoning ability. It requires a rethinking of access control—not just at the point of execution, but at the moment of context delivery.
MCP is new. Its spec is still evolving. That means much of what’s available today is either incomplete, inconsistently implemented, or poorly documented.
Here are some of the practical issues we’ve run into:
**Remote server support is fragile or missing entirely
**Many clients are designed to run locally with STDIO-based servers and require manual workarounds to connect to remote endpoints.
**Environment configuration is clunky **Setting up MCP connections often involves manually exporting environment variables and piping JSON blobs across shell scripts.
**Poor documentation and inconsistent client behavior **Tools like LangChain, Claude Desktop, Open WebUI, and Cursor support MCP differently. That means you're on your own when it comes to interoperability.
**No policy enforcement surface **MCP servers typically do not include native policy enforcement. There’s no consistent way to define what tools should be available, under what context, and to whom.
These gaps don’t mean MCP is unusable—they mean you need infrastructure to bridge what the ecosystem doesn’t yet provide.
One of the most effective ways to bring structure and safety to MCP deployments is middleware. Think of it as a gateway—not just a security tool, but a place to understand, observe, and shape behavior.
Middleware sits between the agent and the MCP server. It can:
This isn’t just a policy engine. It’s the boundary where context meets action. It’s also where debugging becomes possible—because you can now log and inspect agent reasoning before tools are executed.
Frameworks like FastMCP are well-suited for this. They provide extension points for policy injection, observability, and proxy behavior. We’ve also contributed to permit-fastmcp, which layers fine-grained authorization on top.
Too many systems treat consent as a checkbox during OAuth flow. That model doesn’t hold in MCP.
Consent in MCP must account for who is delegating, to which agent, and for what purposes. And it must be revocable and auditable.
When a user gives an agent the ability to send emails, that doesn’t mean “any emails, to anyone, forever.” It should mean “this agent, can send email, on my behalf, to this address, under these circumstances.”
That consent needs to be expressed not only to the upstream service (like Gmail) but also to the MCP server, tool registry, and the agent itself. These are different surfaces and must be treated accordingly.
Treating all of this as one OAuth grant is insufficient. Consent is the foundational link between agent identity, intent, and permission. It needs to be managed explicitly, and enforced consistently.
If you're adopting MCP today, here are the foundational practices we recommend:
**Assign identities to agents **Every agent should have a unique, traceable identity. If it takes action, it must be accountable.
**Use consent as a primary control surface **Don’t limit this to OAuth. Use delegation consent to define scope, relationships, and runtime access. Track it and be able to revoke it.
**Implement middleware **Gateways like FastMCP give you a place to enforce auth, introspect behavior, and add policy checks without relying on incomplete client/server implementations.
**Use fine-grained permissions over token juggling **Tokens are not context-aware. Build a system where policies and relationships drive behavior, not static credentials.
**Interrogate agents as part of your runtime checks **Ask: What tools do you see? Who are you working for? What are you about to do? Use these signals as part of your enforcement strategy.
Agents are becoming the new runtime surface. They carry intent, execute logic, and interface with critical systems. MCP gives them the context to do that well—but it also gives them the power to do it wrong.
Authentication and authorization in MCP systems isn’t a solved problem. It’s a space that still lacks standardization, tooling, and maturity. But the risks are real today, and the need for control is immediate.
We need systems that understand not just who is acting, but on whose behalf, under what consent, and within which contextual boundaries. Without that, we’re just hoping agents behave—and hope is not infrastructure.
Start building for identity. Start enforcing consent. And never let an agent operate without context-aware control. That’s what will make MCP safe, reliable, and ultimately, production-ready.
Co-Founder / CEO at Permit.io
