The Practical Guide to MCP Auth: Identity, Control & Agent Permissions
Ever since the Model Context Protocol (MCP) became the de facto protocol for providing agents with the capabilities they need to sufficiently do tasks, ambitious teams have scrambled to get MCP servers into production. Afterall, MCP offers the missing element that AI agents need to work autonomously: access to tools and data.
However, the promise of MCP did not arrive with all the necessary components to make it enterprise-ready, especially in regards to 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 me to visit a website for mass adoption to take place. Sign-in and authorization, therefore, aren’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.
MCP Is Different from APIs & Other Endpoints
MCP servers aren’t just REST endpoints; they use 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.
MCP servers 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 to 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 security risks, you can’t only have working auth, you also need auditable identities 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
You should run local/workstation MCP servers it in a sandboxed and secure environment like a Docker container, and properly secure remote MCP servers with OAuth. - 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 the agent and the 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 them.
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 that you’ll have attack vectors that 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 (and the video below), 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 for MCP traffic 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 streamable HTTP, which is simpler to understand and, therefore, safer to use.
- Manual config hell – Setup often involves exporting env vars and scripting raw JSON files.
- 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 by an MCP server to an agent 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.
- 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.
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 and making MCP servers suitable for business use, middleware is your best friend. Specifically, an MCP 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 must 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. - Sandbox/Containerize Local MCP Servers
Use Docker, Portainer, or other virtualization technologies to run your MCP local servers in isolation and restrict their 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 solutions 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 basic MCP observability 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. However, most people are running MCP are doing so blind–without proper observability, logging (like in the video below), or security in place.
Tutorial on MCP Logging:
Subscribe to the MCP Digest for free, and stay up-to-date with the latest news and guides to help you use AI and MCP in your organization.
