MCP's Next Battlefield: From Tool Connection to Identity and Permissions

MCP solved a hard problem: how do AI agents discover, connect to, and call external tools? Before MCP, every agent needed custom integration code for every tool. After MCP, a single configuration block connects an agent to any compatible server. The connection problem is largely solved.

But solving connection exposed the next problem, and it's a bigger one: when an AI agent calls a tool, whose identity is it using? And what is it allowed to do?

This is the identity and permission problem, and it's the next major battlefield in the MCP ecosystem. Get it right, and MCP becomes enterprise-ready infrastructure. Get it wrong, and MCP remains a developer toy — useful for personal projects, too risky for business-critical systems.

Why Identity Matters More Than You Think

Let's start with a concrete scenario. You're an employee at a mid-sized company. You connect your company's internal AI assistant to three MCP servers: a hotel booking server for travel, a calendar server for scheduling, and a database server for analytics. The assistant can now book hotels, schedule meetings, and query company data.

Whose identity does it use when it does these things?

If it uses a shared service account — one API key for all users — then every employee's bookings, calendar events, and database queries happen under the same identity. There's no audit trail showing who did what. There's no way to enforce per-user permissions. There's no way to know whether that hotel booking was made by Alice from marketing or Bob from engineering.

If it uses your identity — your personal API key, your user account — then the assistant acts as you. It can book hotels with your travel budget, schedule meetings on your calendar, query databases you have access to. This is more secure and auditable, but it requires the MCP server to understand and respect your identity. And it raises the next question: what if the assistant tries to do something you're not allowed to do?

The Permission Problem

Identity answers "who is acting." Permissions answer "what are they allowed to do." In the MCP context, this breaks down into several layers:

Tool-level permissions. Can this user call this tool at all? A junior employee might be allowed to search hotels but not book them. A contractor might be allowed to query the analytics database but not modify it. Tool-level permissions control which tools are available to which users.

Parameter-level permissions. Even within a single tool, different users might have different parameter constraints. A sales employee might be allowed to book hotels up to $300/night; an engineer might be limited to $200/night. A manager might be allowed to book for any date; a new hire might need approval for bookings more than 30 days out. Parameter-level permissions constrain the inputs to each tool call.

Data-level permissions. When a tool returns data, different users might see different results. A hotel booking tool might return all available rooms to a travel coordinator but only rooms within the user's budget to a regular employee. A database query tool might return full records to an admin but masked records to a regular user. Data-level permissions control what the tool returns based on who's asking.

Rate and budget permissions. How many times can this user call this tool per day? How much can they spend? A hotel booking tool might have a monthly budget per user. A database query tool might have a daily call limit. These permissions prevent abuse and control costs.

Most MCP servers today handle none of this. They use a single API key for all access, with no user identity, no per-user permissions, and no audit trail. This is fine for personal projects and developer experimentation. It's completely inadequate for enterprise deployment.

The Current State: Three Approaches (None Perfect)

MCP server developers are tackling identity and permissions in three ways, each with trade-offs:

Approach 1: Shared API keys with server-side rules. The server issues one API key per organization, and all users in that organization share it. The server enforces some rules — rate limits, budget caps — but can't distinguish between users. This is the simplest approach and the most common today. It's also the least secure: no per-user audit trail, no per-user permissions, no way to revoke access for a single employee without rotating the shared key.

Approach 2: User-specific API keys. Each user gets their own API key, which they configure in their AI client. The MCP server can identify the user from the key and enforce per-user permissions. This is more secure but creates a management burden: users must manually configure their key in every client, administrators must provision and revoke keys, and keys can be shared or leaked. It also doesn't work well for web-based AI clients that can't securely store per-user secrets.

Approach 3: Token exchange and identity propagation. The AI client obtains an identity token for the current user (through OAuth, SSO, or another auth mechanism) and passes it to the MCP server with each tool call. The server validates the token, identifies the user, and enforces permissions. This is the most secure and scalable approach, but it's also the most complex. It requires the AI client to support token passing, the MCP server to validate tokens, and an identity provider that both trust.

The industry is moving toward Approach 3, but we're not there yet. Most MCP clients don't support identity token passing. Most MCP servers don't validate user identities. The protocol specification doesn't yet mandate a standard identity mechanism. This gap is the next major area of protocol evolution.

Real-World Example: How RollingGo Handles Identity Today

RollingGo Hotel MCP shows how a production MCP server approaches identity in the current protocol landscape. Instead of waiting for a standard identity layer, it uses four distinct registration identities, each with different permissions and backend capabilities:

Identity	Who It's For	Key Capabilities	Backend Access
Developer	Building agents or travel programs	Full MCP tools, unlimited calls	Partner Center: markup rates, traffic logs, orders
Enterprise	Company-wide travel integration	Full MCP tools, team management	Partner Center: employee budgets, audit trails, invoicing
Personal	Using AI tools for personal travel	Full MCP tools, no backend needed	Install instructions only — no admin account
KOL (Affiliate)	Content creators with distribution	Full MCP tools + affiliate links	Partner Center: earnings dashboard, H5/mini-program links

Registration is instant — no manual review, no waiting period. Each identity receives a 32-character API key (format: mcp_xxxxx...) that serves as both authentication and identity marker. The key goes in the standard MCP authorization header:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer mcp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

This approach isn't perfect — it's essentially Approach 2 (user-specific API keys) with structured identity tiers. But it solves real problems today: enterprises get audit trails and budget controls through the Partner Center, developers get traffic analytics, affiliates get earnings tracking. And it does it all within the current MCP protocol, without waiting for a standard identity layer.

The lesson for the MCP ecosystem is that identity doesn't have to be all-or-nothing. Structured API key tiers, scoped permissions, and backend dashboards can deliver 80% of the value of a full OAuth identity system, today. The remaining 20% — true SSO integration, real-time token exchange, cross-server identity propagation — will come as the protocol evolves.

Why Enterprises Care About This

For enterprises, identity and permissions aren't nice-to-haves — they're deployment blockers. A company can't deploy an AI assistant that books hotels using a shared service account, because:

• Compliance requires audit trails. Many industries are required to know who made what booking, when, and for what purpose. A shared account makes this impossible.
• Budget controls require per-user limits. Companies have per-employee travel budgets. A shared account can't enforce them.
• Security requires least privilege. An AI assistant that can query any database, book any hotel, and schedule any meeting is a security risk. Per-user permissions limit the blast radius of a compromised agent.
• Privacy requires data segregation. Employees shouldn't see each other's bookings, calendar events, or query results. Identity-based data permissions enforce this.

Until MCP solves identity and permissions, enterprise adoption will be limited to low-risk use cases — personal productivity, information lookup, non-transactional tasks. The high-value use cases — automated booking, financial transactions, data modification — will remain off-limits.

What a Good Identity System Looks Like

The MCP ecosystem doesn't need to reinvent identity. The building blocks exist. What's needed is a standard way to combine them:

OAuth 2.0 for authorization. The AI client obtains an access token from an identity provider (the company's SSO system, or a dedicated MCP auth service). This token represents the user's identity and contains scopes that define what the user is allowed to do.

Token passing in MCP requests. The client includes the access token in each tool call, either as a header or as a standard protocol field. The MCP server validates the token before processing the request.

Scope-based tool permissions. Each MCP tool declares required scopes (e.g., hotel:search, hotel:book, hotel:cancel). The server checks that the user's token contains the required scope before allowing the tool call. This gives administrators fine-grained control over which users can use which tools.

User context in tool calls. The server extracts the user's identity from the token and uses it to filter data, enforce budget limits, and write audit logs. The agent doesn't need to know the user's identity — the server handles it automatically.

Audit logging. Every tool call is logged with the user's identity, the tool called, the parameters passed, and the result. This creates a complete audit trail for compliance and security analysis.

This architecture is well-understood in the API world — it's how most modern SaaS platforms handle authentication and authorization. The challenge is standardizing it for MCP so that any client can work with any server, without custom integration code.

The Roadmap for MCP Identity

The MCP specification is evolving, and identity is on the roadmap. Here's what I expect to see over the next 12–18 months:

Phase 1: Standardized auth headers. The MCP spec defines a standard way to pass authentication tokens in requests. This is a small change but an important one — it gives clients and servers a common mechanism rather than each server inventing its own.

Phase 2: Scope declarations. MCP servers can declare required scopes for each tool in their tool descriptions. Clients can display these scopes to users before connecting, similar to how OAuth apps request permissions. Users can make informed decisions about what they're granting access to.

Phase 3: Identity-aware servers. MCP servers begin validating user identities and enforcing per-user permissions. This requires server developers to build auth systems, but the protocol provides the standard interface.

Phase 4: Enterprise identity integration. MCP servers integrate with enterprise identity providers (Okta, Azure AD, Google Workspace) through SAML and OIDC. This allows companies to use their existing identity systems to control MCP access, without managing separate API keys.

Phase 5: Zero-trust agent architecture. AI agents operate under strict identity and permission constraints, with every action auditable and revocable. This is the end state — MCP as enterprise-grade infrastructure, with security baked in from the start.

What Developers Should Do Now

If you're building an MCP server today, don't wait for the protocol to solve identity. Start building identity-aware features now:

1. Support multiple API keys per organization. Even if you can't distinguish individual users yet, allowing organizations to create multiple keys (e.g., one per team) is a step toward granular access control.
2. Add audit logging. Log every tool call with the API key used, timestamp, tool name, and parameters. Even without user identity, this provides a basic audit trail.
3. Implement rate limits and budget controls. Per-key rate limits and spending caps prevent abuse and give organizations basic cost control.
4. Design for token-based auth. Even if you're using API keys today, structure your code so that switching to token-based authentication later is a configuration change, not a rewrite.
5. Document your security model. Tell users exactly how authentication works, what data is logged, and what permissions are enforced. Transparency builds trust.

If you're building an AI client, prioritize identity support:

1. Support per-user API key configuration. Let users enter their own API keys for each MCP server, rather than using a shared key.
2. Display tool permissions before connecting. When a user adds an MCP server, show them what tools the server provides and what actions those tools can perform.
3. Add confirmation steps for transactional tools. Before the agent calls a tool that modifies data (booking, payment, deletion), show the user what the agent is about to do and ask for confirmation.
4. Support OAuth token passing. As the MCP spec standardizes token-based auth, add support for it in your client. This will be a key differentiator for enterprise users.

The Bottom Line

MCP won the connection battle. The next battle is identity — and it's a harder fight. Connection is a technical problem; identity is a technical problem wrapped in a security problem wrapped in an organizational problem. It requires protocol changes, server development, client support, and enterprise adoption.

But the stakes are high. MCP with identity is enterprise infrastructure — the kind of thing companies build business-critical systems on. MCP without identity is a developer tool — useful, interesting, but limited to personal projects and low-risk use cases.

The servers and clients that solve identity first will own the enterprise market. The ones that don't will be left in the developer ghetto, watching from the outside as the real money gets made elsewhere.

The connection problem is solved. The identity problem is next. Who's building it?

If you're building an MCP server and want to get identity and permissions right from the start, the official quick-start guide covers the basics in five minutes: RollingGo MCP Quick Start.