Securing the AI frontier: A CISO’s guide to access control for MCP

As MCP adoption grows, securing this critical AI infrastructure is essential to prevent data exfiltration risks.

Paddy SR   ·   Monday, December 8th, 2025   ·   Reading Time: 8 minutes

The Model Context Protocol (MCP) has emerged as a critical piece of infrastructure in the generative AI stack. It is the bridge that allows Large Language Models (LLMs) and AI agents to interact with proprietary data and productivity tools. While its adoption accelerates, this MCP bridge, if unsecured, could become a superhighway for data exfiltration and enterprise security leaders must prioritize securing this new, complex frontier.

(Cut to the chase, I know MCP and its challenges…)

MCP glossary

For our human readers, who still enjoy reading blogs, let us start with an analogy. LLM is like a wise librarian who has read every book in the library and could answer any questions, but is confined to pre-trained knowledge. Retrieval Augmented Generation (RAG) enabled users to bring their own add-on data (like current news or enterprise documents) and ask contextual questions.

Tool calling capability helped AI applications to decouple and embrace the Hollywood principle: “you don’t call us, we’ll call you”. It provided ways for our formidable librarian to use specialized helpers at his discretion – not only to fetch information on-demand (from weather service, web search, enterprise datalake etc), but also to take actions (like sending an email or making a transaction) that enables more autonomous AI systems.

MCP defines a standardized way of accessing external systems, the official documentation calls it a USB-C port for AI applications.

MCP security

There could be several security concerns such as injection attacks, tool poisoning, server spoofing etc, that may soon summon a OWASP Top 10 for MCP.

The core security principles of the specification revolve around user consent, data leakage or overprivileged agent capabilities.

So, in this blog post, we focus on authorization.

With great power comes great need for authorization

While it is cool for Ironman to ask Jarvis to “check Palladium levels” or “quickly buy a building”, the stakes are high and it inherently becomes the responsibility of the AI assistant and underlying systems to authenticate the identity, to authorize the request and be overall accountable for the action.

The specification (November 2025) says authorization is optional and transport specific. For HTTP, it rides on top of OAuth 2.1 standards. While it emphasizes decentralization and enables many to many integrations, enterprises might still focus on centralized access control and monitoring.

Anti-patterns

• Relying on LLMs or System Prompts for Access Control: Leaving the access-control job solely to LLMs or system prompts is an anti-pattern, as it lacks a deterministic and auditable solution.
• Internalized Custom Authorization Logic: Internalizing custom authorization logic within the application or MCP server implementation is an anti-pattern. This approach neither scales nor facilitates evolving authorization rules, necessitating externalized, fine-grained authorization.
• Keys to the Kingdom Credentials: The MCP server should not work with highly privileged credentials (e.g., a service account to the database or single static client). The MCP server itself is a vulnerable interface, and an attacker compromising it may gain god-mode access to all the data.
  • Delegated access must be preferred over user impersonation.
  • Relying on network-level security or a simple API key is dangerously insufficient.

Key challenges

• Confused Deputy Problem: The MCP server (the “deputy”) is authenticated and has some privileges (Eg: scheduling meetings). A malicious user may trick the MCP Client with a clever prompt to leak sensitive data (in this example, leak executive schedule or to hijack another meeting). This is a precarious challenge to be solved with Zero Trust access control. The specification proposes mitigation steps, though it adds complexity to MCP proxy and responsibilities for the user to know the technicalities of underlying integrations.
• Coarse-grained OAuth scopes: Standing coarse permissions (e.g., “read:email” for email categorizing agents), even when using short-lived tokens, do not prevent PII or OTP leaking from the email content.
• Sheer number of tools: Tool capabilities are increasing rapidly. For example, general purpose agents like Manus use hundreds of tools. Time-to-market or the competition could cause enterprises into exposing internal services and data without sufficient access control.
• Consent fatigue: The specification relies on users being fully aware of each call and its privacy implications. However when several tools and multiple interactions are involved, the consent process becomes monotonous and users may even choose to “always” allow.

Architecting for control: Options & patterns

Pre-requisite

• Agent Identity & End-user context:  The MCP server can be accessed by end-users delegating their access to AI applications or chatbots. Or it can be used by long-running AI agents or even digital employees with different levels of autonomy.

• It is crucial to establish the identities of the calling application/agent along with any user delegation and propagate the context to the MCP resource server. On the server side, authentication must be covered using OpenID or SPIFFE or other cryptographic standards.
  • With standard OAuth 2.1 flows, the identity and context can be established from the ‘Authorization’ header or the access token which contains client-id, sub, aud etc
  • There are identity standards evolving for AI agents like MCP-I, OpenId and OAuth extensions, SCIM extensions and IdPs like Microsoft Entra and Okta that help govern agentic identities.
  • In certain cases, the resource server can also mandate a custom token like `x-user-token` which can refer to end-users whereas the bearer token would refer to the agent identity.
  • Some enterprise use-cases may demand pre-provisioned OAuth clients with certificates based client-credentials and forbid dynamic client registration or client_id_metadata (CIMD).

Zero Trust authorization

Policy-based, dynamic and fine-grained authorization is the gold standard for achieving Zero Trust in enterprises. Policy-based access control ensures each and every interaction to the MCP server is access controlled dynamically and consistently. The externalized policy helps with scalability and extendability based on evolving standards and authorization needs in the enterprise.

Axiomatics enables orchestrated authorization and provides capabilities for:

• Binary permit/deny decisions for tool, operation level access control
• Reverse query based data filtering for request and response payload

Like the story of stone soup, AI is only a catalyst for MCP and underneath it is json-rpc API and can be access controlled like any other API. Different patterns for policy enforcement are described below.

Axiomatics recommends a defense-in-depth approach, where a combination of multiple patterns discussed below could be applied for robust defense against potential AI attacks.

Below is a representative example of different interfaces and possible enforcement points:

Securing MCP servers

Access control for MCP client side

Advanced patterns with Axiomatics solutions

Key security principles from MCP specification are critical about user consent and user being informed about each operation and data access. However, from a practical standpoint, it is a lot for a non-technical user, who expects convenience from AI applications, to understand the interface specification. Even for a technical user, it becomes monotonous. This consent fatigue is mostly circumvented by users with something like “AlwaysAllow” or “Brave” mode or “DangerouslySkipPermissions” mode.

The key problems here are with monolithic scopes and lack of fine-grained control.

Consent as policy

Axiomatics proposes to solve this by getting policy from the user as consent. The policy, customized by the end-user, would supplement the high level scopes and become associated with an access token. This policy would be enforced on each interaction at the MCP or resource server.

Depending on the application and user personas, this policy customization can be presented to users with various levels of technicality. For example, the screenshots from internal applications demonstrate:

1. How a user can have better control over his data. Instead of delegating “read:email” scope to the client application, the user could say “permit reading of emails from a specific domain”
2. The consent form can be customized for user experience by using a resource metadata standard. In this example, the user can either choose from a set of attributes and functions through the UI-based policy editor or even supply a policy fragment or full blown policy in Abbreviated Language for Authorization (ALFA).

Obligations and elevated access

For high value transactions, Axiomatics also supports authorization with additional obligations and advice. Consider a user wanting to use AI agents for share trading or an executive delegating document access to the secretary. There are certain limits that are specified on normal days and there can be needs for exceptions or elevated controls, in the above examples it could be the trading app wanting to use beyond 500$ or the secretary accessing undisclosed financial statements. Such cases can be allowed with added security that requires just-in-time mechanisms such as transaction tokens or CIBA or OTP from the end user.

In such cases, Axiomatics support access control policies with obligations that need to be completed when a specific operation is permitted or denied.

In summary

The AI applications, their adoption and user demands are evolving faster than their security standards. For enterprise, these access controls are paramount to achieve Zero Trust compliance and avoid any data leaks. MCP is just a piece of a larger puzzle in the world of AI agents and autonomous applications.

There are also other protocols like UTCP for tools and A2A for agentic interactions, to address these comprehensively, stay tuned for updates — or contact us directly for more information.