Plenty of model context protocol (MCP) servers in production authenticate once, with a configured credential, then serve every request that arrives. MCP authorization is also "OPTIONAL" under the MCP specification and applies to HTTP-based transport. An MCP server can therefore comply with the protocol without implementing authorization.
The team setting up the server has to add its own checks on who is asking and what they are allowed to reach. The agent has no way to prove who sent a request, and nothing stops it reading more than it should. Those controls belong in a separate layer before requests reach the server.
What does "enforcing MCP security outside the agent" mean
Enforcing MCP security outside the agent means authorization, least privilege scoping, and audit logging live in an independent control plane the agent calls into, not inside the agent or the MCP server itself. It checks every request before that request reaches the server. The agent is not the one applying the limits, so they hold even when a request asks for more than it should.
Without centralized access controls, a server may use a credential with broad permissions to process requests without verifying whether the user is authorized to access the data. Security teams call this the confused deputy problem, and the agent cannot catch it, because the agent is the component being misled. CData's guide to common MCP server vulnerabilities covers the classes of risk this creates.
Why in-agent security logic fails at enterprise scale
AI agents often use access tokens with broader permissions than their tasks require. Managing access separately for each agent or server leads to scattered configurations and inconsistent enforcement, with no central policy engine.
The Open Worldwide Application Security Project (OWASP) ranks excessive agency, an agent granted more permission than its task requires, among the top risks for LLM applications, and advises authorizing in external systems rather than delegating it to the model. And prompt injection cannot be completely prevented; agents should only have access to the capabilities they need, limiting what a compromised agent can do.
Credential exposure and service account sprawl
Most agents use a single, broadly scoped OAuth 2.0 access token across multiple services. If a server is compromised, that token could expose other services. Configuring authentication separately for each server reduces token sharing but adds complexity as connections, credentials, and environments grow.
With passthrough authentication, the control plane inherits the user's own OAuth or security assertion markup language (SAML) identity at request time rather than holding a shared service account, so each request runs under the real person's permissions, and enforcing it once at the gateway removes custom authentication logic from every server. CData Connect AI enforces user and connection level permissions when an agent invokes a tool, as described in its agent authorization approach.
Missing audit attribution
When agents share a service account, logs record the account rather than the individual user. Activity records are also scattered across agents, servers, SDKs, and APIs, making investigations difficult. A centralized access layer brings these records together, making it easier to trace requests back to their source.
Permission drift and scope creep
As users change roles, their agents may retain permissions they no longer need. OWASP recommends limiting access to each task and running agents under the user's own permissions. An identity provider (IdP) helps keep agent permissions aligned with current user roles and access policies. Managing these permissions becomes harder as more agents and MCP servers are added. This is discussed at length in CData's multi-MCP deployment blueprint.
The governed control plane: a policy layer independent of the agent
A governed control plane acts as a single secure entry point for one or more MCP servers, handling authentication, routing, and policy enforcement, so clients never connect directly to a backend server. Like a reverse proxy, it keeps internal servers shielded and collapses the attack surface to one endpoint. CData's MCP gateway is one implementation of that pattern.
Enforcement concern | In-agent or per-server logic | Governed control plane |
Identity for data access | Shared broad scope service account. | Per user OAuth or SAML identity, inherited per request. |
Audit attribution | Fragmented across agents, servers, and SDKs. | One record per request, tied to a named user. |
Least privilege | Enforced in code nobody re-audits. | Structural, via isolated connections and allowlists. |
Access policies should be managed through the IdP, where security teams can review and update them, while a central control plane enforces those policies. The enterprise MCP security playbook explains this approach in more detail.
How runtime enforcement works: passthrough authentication and RBAC
Runtime enforcement means the authorization decision happens per request, at call time, against the live identity of the person asking rather than settings fixed in the agent's configuration. The Enterprise-Managed Authorization (EMA) extension went stable in 2026 and is being adopted by Anthropic, Microsoft, and Okta.
During single sign on (SSO), the client obtains an Identity Assertion JWT Authorization Grant (ID-JAG) through the IdP and exchanges it for an access token limited to a specific server. The control plane then checks role-based access control (RBAC) permissions for each request, using current policies rather than permissions assigned when the agent was built.
Standard | Role in runtime enforcement | Requirement level |
OAuth 2.1 | Baseline framework MCP adopts. | Authorization servers MUST implement. |
Client ID Metadata Documents | Registration without per server setup. | Servers and clients SHOULD support. |
OIDC or SAML single sign on | Establishes the identity the IdP asserts. | Required for EMA. |
OAuth/SAML identity passthrough
Identity passthrough relies on three standard authentication and token exchange mechanisms. The user signs in through OIDC or SAML, the client exchanges the resulting identity assertion for an ID-JAG using an RFC 8693 token exchange, then presents it as an RFC 7523 JWT bearer grant for the final access token. A SAML assertion takes one extra hop, since it must be exchanged for a refresh token before the ID-JAG request.
The IdP determines access based on current user roles, group memberships, and conditional access policies. A central control plane enforces these permissions before the agent's tool request reaches the server.
Okta is the first IdP to support this approach, while ID-JAG remains an emerging IETF draft. Organizations should confirm compatibility with their IdP. Connect AI takes a different approach, using OAuth and SAML based identity and connection permissions to govern data access.
Least-privilege enforcement and workspace isolation
Least-privilege limits agents to the data objects and actions required for their tasks, with permissions checked on every request.
Workspace isolation keeps connections, credentials, and data access separate. Agents cannot access resources outside their assigned workspace. Tool level permissions add further restrictions by denying tools unless explicitly allowed and hiding unavailable tools from the agent.
Our guides on field level security for AI agents and securing MCP servers in multi-agent deployments explain these controls in more detail.
Audit logging and compliance for every AI data interaction
Query-level audit logs that attribute every AI data interaction to a real authenticated user are only possible when logging happens in a control plane outside the agent, not inside it. Runtime controls help prevent unauthorized actions, while audit logs provide the evidence needed to investigate prompt injection attempts and suspicious agent activity.
SOC 2 Type II, ISO 27001, and GDPR/CCPA alignment
Regulated organizations must demonstrate that their MCP deployments meet relevant security and compliance requirements. One industry estimate places the cost of in-house SOC 2 compliance work for custom MCP servers between $15,000 and $50,000.
Auditors typically review access restrictions, user activity logs, and permission policies. Managing these centrally makes compliance easier to demonstrate. Data minimization under GDPR and CCPA works the same way, since scoping access to the minimum needed is a privacy control as much as a security one.
SIEM export and query-level audit trails
An audit log is only useful if the security team can pull it into the security information and event management (SIEM) platform they already run, which is why SIEM integration sits alongside authentication, rate limiting, and monitoring in gateway best practice, and why the NSA's MCP guidance calls for audit logging wired into SIEM. Each record should carry:
Authenticated user identity: the real person, not a service account.
Agent or client: which application made the call.
Tool invoked: the specific capability exercised.
Target resource: the connection and objects reached.
Timestamp and decision: when it happened and whether it was allowed.
Build vs. buy: the cost of your own MCP security layer
Building a basic MCP server is relatively straightforward, but maintaining it requires ongoing work on authentication, governance, monitoring, and updates. One industry analysis estimates annual costs of $50,000 to $150,000 per custom integration, with monthly maintenance for a moderately complex server costing $1,200 to $2,600.
Cost and risk dimension | Build your own | Buy a governed platform |
Auth and credentials | Per server OAuth, token rotation, identity upkeep. | Inherited runtime identity, handled once. |
Audit pipeline | Yours to build, run, and keep in your blast radius. | Built in, exported to your SIEM. |
Patching and CVE response | Your team's job indefinitely. | Vendor owns patching and disclosure. |
Self-hosting MCP means managing authentication, credential storage, audit logging, and access enforcement internally. A managed platform handles these responsibilities, reducing the operational and security burden on internal teams. The comparison on managed versus self hosted MCP and building versus buying MCP explore these trade-offs.
Enforce MCP security outside the agent with CData Connect AI
CData Connect AI provides a central control plane between AI agents and enterprise data sources. It manages access through source system authentication, connection and field level permissions, and centralized audit logging. Security teams can review these controls to understand how agent requests are authorized and recorded.
The Enterprise-Managed Authorization (EMA) extension reflects a broader move toward centralized access management for MCP. Building and maintaining similar capabilities internally can be expensive, and a managed platform offers an alternative for organizations that want to reduce maintenance while retaining oversight of agent access.
Start a free trial to connect your own data.
Frequently asked questions
What is MCP security, and why does it matter for enterprise AI?
It covers which data and actions an AI agent can reach through MCP. The protocol leaves authorization optional, so without an external layer an agent inherits whatever access its credential carries.
Are MCP servers a security risk?
They can be. A server acts on live systems with whatever credential it holds, so one with a broad token reaches anything that token allows. The risk is in how access is granted and audited.
What are the biggest security vulnerabilities in MCP deployments?
Prompt injection, over privileged access from broad tokens, credential exposure through shared service accounts, missing per user attribution, and permission drift as roles change.
How do audit trails and logging fit into an MCP security strategy?
They provide the attribution incident response depends on, tying each tool invocation to a named user, a resource, and an allow or deny decision, then exporting to your SIEM.
What's the difference between per-agent security logic and a centralized MCP policy layer?
Per agent logic repeats authentication, scoping, and logging everywhere, and drifts as each copy is maintained. A centralized layer enforces one policy for every client.
