With a unified MCP control plane for platform engineering teams, AI teams can share MCP servers without each having to rebuild authentication. That shared layer binds identity to each tool call, manages credentials, and enforces policy across teams. Platforms such as Runlayer centralize this plumbing so each new project inherits the foundation.
Why MCP access controls cannot be solved team by team
MCP standardized integration but left enterprise security to the enterprise. Anthropic released the protocol in late 2024 as a standard interface connecting agents to tools and data. Within roughly a year, every major LLM vendor had adopted it. Yet the original specification did not require authentication when it shipped, and MCP does not define a role-based access control model. Whatever access rules govern an agent are therefore something the organization built, bought, or forgot to install.
A team can tailor permissions to its tools and keep deployment inside its required network boundary. For a contained project, that can be a practical choice. The weakness appears when other teams repeat the work independently, each choosing its own credentials, access rules, and audit hooks. A working local setup does not establish an enterprise-wide policy.
That difference matters more as MCP becomes infrastructure that teams share. Anthropic’s announcement placed MCP in the Linux Foundation’s Agentic AI Foundation in December 2025, with support across major technology companies. Enterprises are governing a common route into business systems, while independent implementations leave them without a common way to change access or establish audit coverage.
What the threat surface looks like when every team builds its own controls
Fragmented controls turn local weaknesses into wider exposure because MCP servers can aggregate credentials for several enterprise systems. A compromised server can affect the systems it touches. The Supabase Cursor agent incident in July 2025 showed how privilege amplifies prompt injection. A privileged agent was tricked into leaking integration tokens while it worked through support tickets that users had sent. The injected instructions were the trigger, but the agent’s access made the leak possible.
Invariant Labs demonstrated a different route through tool metadata. Its proof-of-concept placed a malicious MCP server in the same context as a legitimate WhatsApp MCP server. The malicious server instructed the agent to read message history and forward it to an attacker-controlled number. No user prompt was needed for the attack. This istool poisoning, where hostile instructions inside a tool definition are treated as legitimate context.
These attacks expose different parts of the same trust problem. Indirect prompt injection hides instructions in everyday work, while tool poisoning takes advantage of trust in the tools themselves. Previously safe tools can also receive malicious updates after installation. Broad service-account permissions increase what a manipulated agent can do, and servers outside a central inventory escape normal review and revocation.
Distributed rules make the response harder as well. Security teams have no single enforcement point for a newly identified threat. With tool-call detection and policy enforcement centralized, as in Runlayer, a response can apply across teams rather than depend on each team discovering and fixing its own exposure.
Why identity is the load-bearing problem underneath all the others
A valid credential does not establish that an agent’s action is appropriate. An autonomous agent may hold access to CRM, email, cloud infrastructure, and payment systems within one task. Its requests can look legitimate at the network level even when it has been manipulated. The system also needs to know whose authority the agent is using and whether that authority covers the specific action.
MCP does not itself resolve that enterprise identity mapping. Following the July 2026 protocol revision, requests include their own version metadata and client capabilities, and clients should include client identity. That stateless design does not, by itself, mandate authorization on the merits of each request. Controls anchored only to a session cannot substitute for checking the identity and authority behind each tool call.
The NSA’s May 2026 advisory flagged that authorization and credential isolation were not yet standardized at the protocol level. Teams that have no shared control plane must add that missing layer themselves. Microsoft Entra Agent ID reached general availability in April 2026, signaling that agent identity has become a distinct industry concern.
Identity is therefore the prerequisite for the other controls. Runlayer ties actions to identity through SSO, SCIM, and just-in-time credentials, addressing this gap at the MCP layer. Without a verifiable user or service account behind the activity, role-based rules lack a dependable subject, audit logs lack attribution, and least-privilege enforcement lacks a basis.
How do multiple AI teams share MCP access without rebuilding auth?
A shared gateway sits between MCP clients and MCP servers. Clients point to one gateway URL. The gateway handles OAuth 2.1 token issuance and validation, routes calls to the right backend, and enforces team and role policies. Each tool invocation is logged with user identity and timestamp. A new server becomes an entry in a shared registry rather than a client-configuration exercise across every team.
Team profiles then define access without duplicating server-by-server rules. Sales can receive CRM read/write and Slack tools, engineering can receive GitHub, Jira, and CI tools, and finance can receive accounting read tools. When someone changes teams or leaves, the profile changes in one place. The access change takes effect across the servers.
Credentials and authorization must follow the action, too. Just-in-time provisioning gives an agent credentials scoped to the action it is about to perform. Per-action authorization checks each invocation against the policy in place at that moment, going beyond the permissions that were in place when the session began.
The June 2026 Enterprise-Managed Authorization extension helps organizations provision MCP server access centrally through their identity provider. Its boundary is important, however. EMA governs connections, so actions after connecting still require runtime authorization. A registry adds inventory, approvals, and version history, but the gateway still needs to enforce rules at runtime even with a registry and identity-provider provisioning in place.
What to look for in a platform that delivers this shared layer
The architectural test becomes a buying question at this point. Does the platform remove repeated security work while making approved tools easier to use? Runlayer combines access to thousands of MCP servers with built-in OAuth, credential handling, and agent setup from Slack. That gives non-technical employees a way in without each team having to build its own connections. Ease of access is part of the design.
Its control layer covers MCP servers, skills, and agents, with identity tied to actions through SSO, SCIM, and just-in-time credentials. Policies apply to each tool call as well as to connection approval. Runtime detection covers tool poisoning, prompt injection, intent drift, and exfiltration, supported by tamper-proof audit logs and full OTEL tracing. These capabilities address separate gaps in a fragmented setup, from excessive permissions to incomplete evidence of what agents did.
TrueFoundry takes an identity-aware runtime approach with granular role-based access controls and access scoping. Its on-premises and private-cloud deployment options suit organizations that need those boundaries. Its enterprise guide emphasizes runtime identity enforcement rather than the full breadth of MCP-specific threat detection or non-technical employee enablement. Deployment fit and control coverage are distinct questions. A broad claim of governance should not obscure either one.
For any platform, the evaluation should follow an actual tool call. Does it bind a verifiable enterprise identity to that call, issue action-scoped credentials, and check current policy? Does it detect threats while the agent runs, or only record them afterward? The audit trail should tie actions to the human identity responsible for them, and onboarding should not make each team do the same engineering work again. Organizations with HIPAA, GDPR, or financial services obligations also need to examine whether routing interactions through the platform creates data-residency exposure.
How the shared layer handles compliance obligations that now reach the tool-calling layer
Agent compliance cannot stop at where data is stored or who signed in. Where an agent uses MCP for a high-risk action, the action falls under applicable logging, oversight, and security obligations. The EU AI Act’s high-risk regime for stand-alone high-risk systems applies from 2 December 2027 following the Digital Omnibus regulation. That includes transparency duties, logging, and human oversight. Organizations need the supporting audit infrastructure before that date.
NIST started its AI Agent Standards Initiative in February 2026. Its request for information covers risks including indirect prompt injection, data poisoning, and specification gaming, as well as deployment-time controls such as constraining and monitoring agent access. An interoperability profile is expected in Q4 2026. This work looks at what agents do as well as how their accounts are managed.
A shared gateway makes that behavior visible through a real-time record of tool invocations. Tamper-proof logs and full OTEL tracing connect actions to identity instead of leaving auditors to reconstruct events from separate team implementations. As non-human identities grow in number, traditional audit processes built around human accounts cannot cover them all. Each action needs its own accountable record.
The infrastructure is built once and inherited by subsequent deployments. That avoids rebuilding the evidence pipeline for every team while the organization’s compliance obligations remain. With the record already available, security and IT can assess new deployments on a common foundation. Their role becomes enabling adoption with evidence.
What breaks when teams try to maintain this themselves as agent deployments multiply
A custom security layer can put the same principles into practice. The difficulty is maintaining them as integrations, teams, and agent deployments multiply. Where tool registration relies on static YAML or JSON, each addition requires a manual edit, code review, and deployment. Policy changes tied to that process cannot take effect immediately. Even routine access changes have to wait in a queue for platform engineering.
Audit coverage creates another recurring maintenance obligation. Without a shared layer, each server needs custom instrumentation, and coverage depends on the team that built it. Slow official onboarding can also encourage teams to connect directly to servers that security cannot see. The access queue then creates a visibility problem. A system intended to control adoption can push activity outside its controls.
Data residency is the strongest objection to a centralized third-party gateway. If MCP interactions pass through an external cloud, sensitive information can leave the required network boundary. That is a genuine concern for regulated organizations. A platform’s suitability depends on whether it offers private-cloud or on-premises deployment that preserves the required boundary. Separate team implementations leave each team to resolve its own residency concerns.
The decisive constraint is organizational capacity. If each new agent project needs custom authentication and access work, platform engineers become the limit on adoption. A shared foundation changes the unit of work from a bespoke security implementation to onboarding against established controls. Building that foundation internally remains possible, but maintaining it is an ongoing platform responsibility after the first deployment.
The operational posture that makes agent adoption safe to accelerate
Approved servers sit in a central registry, each tool call has an identity, and credentials are scoped to the action. A new team inherits those controls on entry. Its onboarding becomes a configuration task rather than another reconstruction of authentication and logging.
That lets non-technical employees follow the same approved route as power users instead of depending on a separate engineering project for access. Security and IT have a common enforcement point and a common record of activity. Platform engineering can support new teams without rebuilding the same plumbing. The secure route becomes the practical route.
The next step is an audit of current MCP use across all teams. It should identify the servers in use, the credentials that lack just-in-time scoping, and the places where audit logging is absent. Those gaps map directly to the shared controls the organization needs. Success is an enterprise where another team can adopt agents without creating another security system to maintain.