Unified MCP Control Planes That Eliminate Per-Project Auth Sprawl for Platform Engineering Teams
Unified control planes centralize MCP credentials and access policies across projects.
A unified MCP control plane lets platform engineering teams give more than one AI project access to enterprise tools without having to rebuild authentication for each one. It puts credential management, tool-level access policy, approvals, and audit in one enforcement layer that agents and tools share.
How independent team-level MCP wiring creates an N×M credential matrix
Five agents that each need ten enterprise tools have fifty separate integration paths. Each path needs credentials, permission scopes, upkeep, and an owner who can revoke access. When teams build those connections on their own, they have to repeat work across projects each time they add a tool and across tools each time they add an agent. That is the N×M matrix platform teams inherit.
MCP standardizes tool discovery and invocation through its host, client, and server architecture. It does not remove the operator’s security work. Wiz Research describes authentication, authorization, and transport security as controls that implementers must supply, rather than protections that follow automatically from using MCP. In practice, developers paste long-lived tokens into local configuration files, set scopes once, and move on. No central owner has a complete map of which agents can reach which systems.
That missing map becomes harder to reconstruct as adoption spreads. Wiz found MCP servers in the vast majority of observed cloud environments in early 2026, with a meaningful share running internet-facing servers. Governance is already trailing deployment in those environments. Narajala and Habler, of AWS and Intuit, explain why ordinary API security practices remain important but are insufficient for MCP’s dynamic, tool-based model. Operators must govern access that agents discover and use at runtime as well as store credentials.
Why per-project auth is the proximate cause of MCP's most serious attack vectors
Fragmented credentials turn local configuration choices into shared exposure. A server with broad scopes and no per-action authorization can become a confused deputy, performing unauthorized actions after an attacker influences model inputs. Wiz says that a compromised intermediate service can reuse those tokens to attack more targets. Token passthrough creates a related failure when an agent uses a human session or shared service account key. The account’s combined privileges replace the end user’s actual permissions, widening the reach of a leaked credential.
Tool poisoning attacks the decision before the call. Invariant Labs demonstrated this in April 2025 with a poisoned math tool that read SSH keys and exfiltrated them encoded in a function parameter. Wiz describes how the user saw no visible trace because confirmation dialogs did not display the full tool arguments. Separate connector weaknesses enable server-side request forgery when tool-supplied URLs reach internal endpoints or cloud metadata services without egress allowlists or URL scheme validation. When session binding is weak and server attestation is missing, there is another way in for session hijacking and rogue server registration.
The Postmark MCP incident in September 2025 exposed the supply-chain side of this problem. A copycat package impersonating the official Postmark MCP server introduced a hidden BCC in an update, silently sending every agent-sent email to an attacker-controlled domain. Wiz reports that the package behaved legitimately at installation and passed standard review before its behavior changed. No user had to make a mistake. Old Dominion University’s MCP-DPT research locates persistent defense gaps at host orchestration, transport, and supply-chain layers, where project-by-project security leaves ownership unclear. Consistent authentication and scopes make these attacks harder, but runtime and supply-chain controls remain necessary too.
What the MCP 2026-07-28 specification change does and does not fix
The MCP 2026-07-28 specification strengthens the foundation by making the protocol stateless and tightening authentication requirements. Removing persistent sessions closes that route for session-hijacking, and removing unsolicited server-initiated prompts stops another kind of unwanted interaction. Those are substantive changes, not cosmetic ones. They reduce protocol-level exposure without removing the need for an operator to govern credentials, access, and execution.
The authorization requirements need careful reading because their scope is conditional. OAuth 2.1 with PKCE is required when authorization is implemented on remote MCP servers, but authorization itself remains optional, and HTTP-based servers SHOULD rather than MUST conform. RFC 8707 Resource Indicators are required to prevent token replay attacks. PKCE with S256/SHA-256 applies to both confidential and public client applications. Stronger rules for an implemented control are not the same as universal deployment of that control.
The revised protocol also creates work elsewhere. MCP-Method and MCP-Name HTTP headers introduce protocol-confusion and secrets-leakage risks if developers map credentials into headers visible to proxies, load balancers, and logging systems. Long-running asynchronous tasks can enable denial of service when an attacker starts an expensive operation and disconnects immediately. MCP Apps bring browser risks, including stored XSS, into the picture as a first-class extension. With sticky sessions removed, authentication, state management, and credential lifecycle decisions fall to gateways and operators. The better protocol still needs an enforcement layer to carry out those decisions in the same way across gateways and operators.
How do platform teams centralize MCP access without rebuilding auth for every project?
A unified MCP control plane is between every agent and every tool. Its gateway intercepts requests, resolves credentials from a central store, routes calls to the correct upstream service, and standardizes responses without requiring changes to the agents themselves. The connections still exist, but their security plumbing is shared. Projects share one layer for identity, policy, and audit across their credential paths, so each project no longer has to manage its own path.
Tool access governance checks what is allowed to run before it runs. Acting as an MCP firewall, it enforces permissions at tool-call depth rather than treating access to a server as permission to use everything on it. Unified authentication connects OAuth 2.0/2.1 flows to enterprise identity providers such as Okta and Azure Entra ID. Role-based access policies then let a marketing team’s agent reach CRM tools but not engineering database tools. Each MCP server no longer has to recreate that boundary independently.
Centralized credential management replaces static keys with task-scoped access. An agent authenticates using its own identity, requests a scoped short-lived credential, uses it, and lets it expire. A human must approve actions that could have serious consequences before they run. SSO and SCIM tie actions to real identities, while behavioral verification checks whether an agent stays within the bounds set for it. Runtime observability and tamper-proof audit records tie each tool call to that identity across the chain, avoiding the attribution gap created by shared service accounts. Narajala and Habler describe the governing principle as Zero Trust, combining continuous verification and least privilege without inherently trusting any agent or server.
How AWS, Microsoft, and Kong have implemented control plane patterns in practice
AWS Bedrock AgentCore approaches the problem through a shared platform gateway. Line-of-business teams expose their data and tools as MCP servers, while the platform account’s AgentCore Gateway gives agents one endpoint for discovery and invocation across registered teams. The gateway uses MCP over Streamable HTTP, fetches Protected Resource Metadata, and supports 3LO Authorization Code with PKCE, 2LO Client Credentials, and IAM SigV4 for AWS-native services. Its deep integration with AWS identity and IAM makes it a natural fit for organizations already running workloads there.
Microsoft starts with the agent’s identity and lifecycle. Entra Agent ID became generally available in April 2026, followed by Microsoft Agent 365 on May 1, 2026. Each AI agent gets its own Entra Agent ID for identity, lifecycle, and access management. The model integrates with Conditional Access, identity protection, identity governance, and network controls. Its emphasis is making agents governable through enterprise identity systems rather than leaving them behind shared account credentials.
Kong builds on the control point it already has for API management. Kong AI Gateway brought that platform into AI, and Agent Gateway in the 3.14 release in April 2026 added governance for LLM, MCP, and agent-to-agent communication. Teams that already use Kong can use that familiar base to control traffic across more than one protocol. The three approaches therefore enter through different doors, namely AWS-native gateway integration, enterprise agent identity, and API governance. Their presence establishes the control plane pattern in practice, but a gateway or identity capability alone does not establish complete coverage of runtime threats, credential provisioning, approvals, and audit.
What a purpose-built unified platform adds beyond gateway-plus-identity patchwork
A routing gateway, identity integration, and separate monitoring tool can leave platform teams reconciling boundaries that projects previously managed on their own. A purpose-built unified platform adds enablement, control, and security in the same traffic path, so the system that permits a tool call also has the context needed to assess and record it.
Routing alone does not detect MCP-specific runtime threats. Tool poisoning, prompt injection, intent drift, and exfiltration need checks built to detect them where traffic passes. Authentication alone also does not supply just-in-time credentials or enforce policy at tool-call depth without additional tooling. For separate audit systems to produce a tamper-proof record of the full agent-tool chain, that chain must pass through a common enforcement layer. The MCP-DPT research’s findings about host orchestration and transport gaps explain why a collection of tool-level defenses can still leave the workflow exposed.
A complete platform therefore has a concrete scope. It provides one view over MCP servers, skills, and agents, with SSO, SCIM, and just-in-time credentials connecting identity to each action. The platform checks policy before each tool call and uses real-time detection to check for MCP-specific threats while tools are in use. Tamper-proof audit logs and full OTEL tracing provide the corresponding record. These are coverage criteria. When they work together, security and IT teams can enable company-wide AI adoption instead of rebuilding authentication plumbing for every new project.
The compliance obligations that make a single audit trail a legal requirement, not a best practice
Regulation adds a second reason to preserve the full record. Fragmented project logs make it difficult to connect an agent’s identity, permissions, approvals, and actions into one accountable chain. A unified control plane provides that chain as part of execution. The legal distinction is important, however. An obligation to keep records or support oversight is not, by itself, a mandate to buy a particular architecture.
The EU AI Act, Regulation (EU) 2024/1689, applies in part from August 2, 2026, covering transparency, governance, and penalties. The Digital Omnibus defers high-risk AI obligations to December 2, 2027, for Annex III and August 2, 2028, for Annex I. The control plane’s audit and approval functions support the recordkeeping and oversight obligations associated with Articles 12, 14, and 26, but deploying the architecture alone does not establish compliance. Applicability and the relevant implementation dates still govern the obligation.
Security frameworks also call for these controls, though the frameworks themselves are not law. The OWASP MCP Top 10 catalogs token mismanagement and shadow MCP servers among the protocol’s leading risks, both closely tied to missing access visibility. The NSA’s Artificial Intelligence Security Center put out its Cybersecurity Information Sheet on MCP security design considerations on May 20, 2026, as federal guidance distinct from the Act’s legal requirements. Together, these pressures make untracked credentials and disconnected records harder to defend.
