The Practical Guide to MCP Auth: Identity, Control & Agent Permissions
Ever since MCP became the de facto protocol for providing agents with the capabilities they need to sufficiently replace humans (kidding, sort of), ambitious teams have scrambled to get MCP servers into production. And for good reason: the Model Context Protocol offers the missing element that AI agents need to work autonomously: access to tools and data.
However, the promise of MCPs did not arrive with all the necessary components to make it enterprise-ready, especially around security.
To make things more complicated, the MCP spec is incredibly opinionated about authorization. Many other protocols (e.g., REST) allow you to just plug in your favorite authentication or authorization method. However, MCP is not trying to be just a protocol; MCP is destined to become an ecosystem where clients can connect to any server with minimal friction. This ease must be akin to how simple it is for you and I to visit a website for mass adoption to take place. Sign in and authorization, therefore, isn’t always required.
OAuth with Dynamic Client Registration is just one example of how MCP servers differ from traditional APIs (and why it’s so hard to safely implement MCP-powered agents). That’s why we wrote this guide.
MCPs Are Different from APIs & Other Endpoints
MCPs aren’t just REST endpoints; it’s a protocol designed to stream structured tool definitions and contextual knowledge to AI agents so that they can reason through decisions instead of following static, deterministic workflows.
An MCP server acts as the source of truth for these workflows. MCPs broadcast available tools and resources to agents so that the agents can interpret context and decide what to do.
This shift away from deterministic API orchestration to a context-driven inference opens new doors. However, it also expands the attack surface, making MCPs more prone toward vulnerabilities.
Attacks are going to get more sophisticated and even smart folks are going to get duped en masse.” – one of many Reddit comments highlighting the security risks of MCPs
To mitigate these secure risks, you can’t only have working auth, you also need auditable identity and scoped consent. In addition, you need enforcement and policies that work in the real world. Let’s explore why.
The 5 Layers of Auth You Can’t Ignore
MCP architectures aren’t single-flow systems; instead, they’re complex webs of actors, contexts, and permissions.
An adequate security model needs to account for all of the following:
- Agent Identity
Agents must have unique, traceable identities. Shared tokens won’t cut it. Every action must be attributable. - User Authentication (Delegator)
The human must authenticate and explicitly delegate control. This control must extend beyond login; human users must also be able to grant authority. - Delegation Consent to Agent
The (human) delegator must define clear boundaries. Which agent? Which permissions? Under which circumstances? - MCP Server Access
As discussed already, MCP servers are either local, in which case you should run it in a sandboxed and secure environment like a Docker container, or you should ensure the remote MCP is properly secured with OAuth or an API token. - Access to External APIs
Many tools interface with upstream and downstream third-party systems. Permissions must carry through cleanly to these systems based on both agent and delegator.
If you skip any of these, you can find yourself having useless logs, fuzzy accountability and rogue agents that operate in the dark, or worse, exposed secrets that compromise your valuable data.
Context Isn’t Metadata. It’s Executable Power.
MCP’s magic is context delivery, which is what also makes MCP so risky.
When a tool is exposed to an agent, the agent, by default, has unfettered access. This extra context can make agents confused with all of the data and tool call options available to it. By making fewer tools available, you’ll get a more focused agent and better results. In addition, reducing how much context an agent can access reduces the likelihood you’ll have attack vectors they bad actors can exploit.
The context MCPs deliver isn’t limited to just capabilities and data within an app; it can also include suggested prompts or behavioral cues, which influence how an agent acts (not just what it calls). That influence is dynamic, invisible to most monitoring tools, and easy to manipulate.
We already unpacked a lot of the emerging MCP security risks in another article, but to quickly summarize, they include:
- Prompt Injection – Malicious prompts hijack the agent’s reasoning
- Confused Deputy – Agent acts under Delegator A while receiving context influenced by another party
- Data Leaks via Tool Chaining – Agents passing between toolsets or servers can unintentionally cross security boundaries (e.g., giving a customer’s social security number from a customer database to a CRM like HubSpot)
In addition, we can’t emphasize enough that agents have non-deterministic behavior, making it all the more important to have security layers that ensure they don’t compromise your business and exfiltrate or delete valuable data.. The same input given to an agent three days in a row might provide three different sets of outputs, so make sure that under no circumstances can your agent destroy or exfiltrate sensitive data. This is why logging is very important.To provide AI-ready security, your access control must move upstream, away from API calls and toward context delivery because context delivery is where intent originates. Ultimately, we want agents that fulfill the workflow’s intent with minimal exposure to security risks.
Today’s MCP Ecosystem Falls Short In Key Areas
MCP launched less than a year ago. Therefore, the MCP spec is still maturing. A byproduct of that is that client/server tooling is inconsistent.
Here’s what you’ll likely run into today:
- Poor support for remote servers – Many systems assume local execution with minimal remote auth handling.
- Competing transport protocols – The spec originally didn’t support remote servers, and first used SSE as its initial transport protocol. Even though it’s been only a short amount of time since its inception, it’s largely being deprecated in favor of StreamableHTTP, which is simpler to understand, and therefore safer to use.
- Manual config hell – Setup often involves exporting env vars and scripting raw JSON files.
- Fragmented tooling – Not all MCP-compatible platforms (LangChain, Claude Desktop, Open WebUI, Cursor, etc.) support OAuth. While they all behave the same way when connecting to MCPs, it’s not a universal experience when enabling authorization.
- No built-in policy layer – Most servers don’t let you define rules for which tools are available under which contexts. Limiting the number of tools that are exposed to an MCP server allows admins to optimize the context length of prompts flowing through the system; this leads to better inference results, fewer dead ends, and more savings.
None of these are fatal. However, they all mean you’ll need infrastructure to fill the gaps.
The Missing Gateway to Secure MCP Servers
When it comes to securing MCP and agent data flows, middleware is your best friend. Specifically, a gateway that can secure, provision, monitor, and log data flows between agent and MCP servers, along with EVERYTHING the agent decides to do with the capabilities it has because of MCPs..
MCP Manager offers such a gateway, allowing you to:
- Authenticate both agents and users
- Log decisions and actions
- Evaluate consent and delegation rules
- Filter tools based on policies
- Block unsafe behavior in real-time
Think of MCP Manager as the configurable firewall for agent reasoning. Check out the video of how it works below:
Why Consent Must Be Explicit, Contextual, and Enforced
In traditional OAuth, “consent” often amounts to a checkmark and a timestamp. That’s not enough here.
In MCP, consent must specify:
- Which agent is acting
- What they’re allowed to do
- On whose behalf
- Under what constraints
The authentication and what it provisions needs to be maintained across all these different technologies.
Treating this as a single OAuth grant isn’t just naive—it’s dangerous. Consent must be auditable, revocable, and contextualized.
If You’re Adopting MCP, Do These 7 Things First
- Give agents real identities
Tokens aren’t enough. Make every action traceable. - Elevate consent as a primary surface
Go beyond OAuth scopes—use delegation records to define and control relationships. - Deploy middleware early
Don’t wait for servers to support policies natively. Gate behavior with your own enforcement layer. - Avoid static credentials
Build systems where permissions flow from relationships, not hardcoded tokens. - Ask your agents what they’re seeing
Log context. Inspect planned actions. Make runtime decisions based on what agents intend, not just what they execute. - Ensure all MCP local servers are sandboxed
Use Docker, Portainer, or other virtualization technologies to ensure your MCP local servers are run in isolation and don’t have access to the host’s filesystem. A major benefit of remote MCPs is that you don’t need to worry about file system access. - Consider using an MCP Security Gateway
As discussed in the above section, middleware is your friend when it comes to MCP security. Consider using a gateway like MCP Manager to help secure, log, and monitor agent <> server activity.
Visibility + Control = Security
MCP gives agents the ability to think and act autonomously, unlocking AI’s true potential. However, it also gives them new ways to go off the rails. However, the tradeoff doesn’t have to be so extreme. If you take precautions and explore looking (like MCP Manager), you can safely implement MCPs across your org.
Even though the current state of authentication, consent, and control in MCP ecosystems is still a work in progress, it’s still possible to build systems that answer these questions:
- Who is acting?
- On whose behalf?
- With what permissions?
- Under what influence?
Agents are no longer just tools anymore; they’re decision-makers. This fact makes security more about intent (and not just about endpoints). Start with identity and make consent explicit. Enforce boundaries with policies and log everything. Better yet, have monitoring in place that can set off warnings if any suspicious or odd activity happens.
When your organization has done this, you’ll be ready for MCP-powered agents.
