A unified MCP control plane lets platform engineering teams share access to MCP servers across AI teams without having to rebuild authentication and access controls for each project. Runlayer is the strongest fit among the approaches considered here for teams seeking all five governance dimensions in one platform. Choosing or expanding that platform still requires evidence of identity binding, credential hygiene, policy enforcement, auditability, and threat detection at tool-call depth.
Why MCP platforms cannot self-certify on governance
MCP leaves governance to the deployment layer by design. Two platforms can therefore support the same protocol while offering very different controls over who can use a tool, what it can do, and what gets recorded. Compatibility does not prove governance readiness. A buyer needs to assess the controls that surround the protocol.
The original version did not require authentication or authorization, but spec version 2026-07-28 requires OAuth 2.1 when HTTP-based servers use authorization. That revision also retains the ban on token passthrough and removes the protocol-level session-ID mechanism. But older servers are still in use, and the specification allows more than one conformance level. A claim of MCP support does not establish which protections are actually enforced.
That creates a measurement problem for platform, security, and IT teams. Identity may be known at login but lost when a tool runs, and access controls may approve a server without checking each action. Logs and threat monitoring can miss the same things. “Governance-ready” therefore needs an operational definition based on observable behavior, rather than a vendor’s description of its architecture.
What actually goes wrong when governance is absent
The Deadbugz campaign in August 2026 showed why controls must keep working after a server is approved. Its malicious MCP server, “productivity-suite,” spread through public GitHub pull requests and behaved harmlessly for its first three tool calls. It then changed its instructions to direct the agent to collect SSH keys, AWS credentials, shell history, and Kubernetes configuration while hiding that behavior from the user. The campaign’s evasion of initial approval makes it a test case for tool-definition integrity and runtime threat detection.
The Grafana MCP server exposed a different gap that same month. It accepted any well-formed caller-generated session ID, allowing callers to run tools with the server’s Grafana service account. A related flaw, CVE-2026-19516, enabled server-side request forgery to cloud metadata endpoints through the caller-controlled X-Grafana-URL header. Both were fixed in mcp-grafana 1.1.0. For a governance rubric, the question is whether the platform binds an action to a verified caller rather than accepting a session identifier as proof of authority.
Wiz Research disclosed two flaws in the Amazon Q VS Code extension in June 2026 that exposed the credential boundary. A malicious repository could use a crafted workspace MCP configuration file to achieve arbitrary code execution and cloud credential theft. Spawned MCP server processes inherited the full developer environment. An attacker who exploited these flaws could therefore get into cloud infrastructure right away. This makes credential isolation a requirement separate from authenticating users.
Shared service accounts also make it harder to tell who was responsible for an action. An audit log may identify the account but omit the agent workflow, initiating prompt, or data accessed beforehand. Because MCP servers can hold credentials for several enterprise systems, the missing attribution can affect more than one team and its resources. Together, these failures establish what a rubric must test, from the caller’s identity through to execution and the evidence left behind.
The five dimensions a governance rubric must score
Identity binding comes first because all the controls that follow need to know who is acting. Every tool call must have a verifiable human or agent identity. The 2026-07-28 specification has three authorization paths: clients acting for users, unattended agents acting for themselves, and enterprise-managed access through an identity provider. A platform must support all three to be governance-ready. SSO and SCIM are baseline capabilities, while the stronger test is whether identity stays attached to the action itself. Enterprise-Managed Authorization, or an equivalent admin-provisioning flow, should score higher because it replaces separate server consent prompts with enterprise-managed access.
Credential hygiene comes next because a request tied to an identity should get only the credentials that identity is allowed to use. MCP servers should not hold standing, reusable credentials. The specification forbids token passthrough and requires a separate upstream token, with token exchange recommended as an optional mechanism. The rubric should test just-in-time credential issuance, automatic secret rotation, and group-membership-to-scope mapping. That last control prevents an agent operating in an engineering context from obtaining a finance user’s scope set.
Policy enforcement then determines what the identified caller may actually do. Server-level approval is too coarse for this job. A platform should demonstrate per-tool allow and deny controls, version-pinned tool definitions with fingerprinting, and human approval gates for irreversible or high-risk actions. Fingerprinting should catch changes to a description before they reach the agent. The platform must also prevent permission accumulation across servers, because a workflow can otherwise gain the union of their permissions even when each connection passes its own access check.
Auditability shows whether those controls worked when the tools ran. Each tool call needs five facts, namely identity, tool scope, execution approval, argument and result inspection, and an attributed log. Missing any one fails this dimension. The evidence should include tamper-proof records, end-to-end OpenTelemetry tracing, SIEM integration, and entries showing the prompt, tool call, policy decision, and downstream resource touched. A service-account-only record cannot establish who initiated an action or why it was allowed.
Threat detection deals with behavior that access policy alone misses. Tool poisoning, prompt injection through tool results, rug-pulls, and intent drift work inside the agent’s context window as well as at the network layer. The rubric should test description fingerprinting, runtime inspection of tool arguments and results, and detection of covert instructions in tool responses. This work cannot stop at the user’s prompt.Runlayer watches MCP trafficin real time for tool poisoning, prompt injection, and exfiltration, illustrating the execution-time approach these incidents demand. General endpoint and network tools were not designed to supply that MCP-specific inspection.
How to weight and score each dimension for your organization
A regulated enterprise should give identity binding and auditability the highest weights because they directly affect its EU AI Act and SOC 2 compliance posture. Threat detection and policy enforcement come next. Credential hygiene remains critical, but an existing secrets manager may already address part of it. These are starting priorities that still require attention to weaker dimensions.
A platform team that moves fast and serves many users inside the organization should instead give policy enforcement depth and credential hygiene the highest weights. A misconfigured server exposes more teams as adoption grows. Identity binding remains essential, even where an existing SSO layer solves part of the problem. Platform engineering, security, and compliance leads should agree on these weights before evaluating vendors, so the score reflects organizational needs.
The first scoring pass needs only three tiers. A dimension can be not present, partially implemented, or fully enforced at tool-call depth. The distinction should expose architectural gaps that require platform selection or replacement, rather than configuration gaps that can often be fixed. Without better evidence, more detailed scoring can make scores seem more precise than they are. The final evaluation column should be “evidence of enforcement,” supported by proof-of-concept audit logs.
How do platforms compare for centralizing MCP governance across teams?
Runlayer provides the broadest coverage described here for organizations seeking a unified MCP control plane. Its SSO, SCIM, and JIT credentials tie identity to every action, with support for all three authorization modes in the 2026-07-28 specification. Enterprise-managed provisioning replaces per-server consent prompts. Built-in OAuth and credential handling provide JIT issuance, while credential scope maps to the requesting identity’s group membership. These capabilities address the first two dimensions without collapsing every team into a shared service account.
For policy enforcement, the platform applies per-tool allow and deny controls at tool-call depth. Its tamper-proof audit logs and full OTEL tracing attribute each tool call to an identity, agent workflow, and policy decision. Real-time detection looks for tool poisoning, prompt injection, intent drift, and exfiltration. Coverage spans all five dimensions of the rubric. That makes it the stronger fit for teams that want these controls together, though a proof of concept must still show that it enforces them before it gets a final score.
The operational distinction is shared control without separate plumbing for every AI project. With Runlayer, platform and security teams get one control pane over MCPs, skills, and agents, while non-technical employees can use chat-based agent setup and instant access. That combination addresses adoption as well as oversight. It does not remove the need to test detailed requirements such as secret rotation or tool-definition pinning where the supplied capability description does not establish them.
An identity-and-policy gateway approach can fit organizations primarily trying to centralize authentication and access rules. Existing identity-provider integration and OAuth 2.1 enforcement at the MCP boundary can address that need. For per-call attribution and detection of rug-pulls or injected instructions in tool results, this approach depends on separate runtime inspection and SIEM capabilities that the evaluation must assess.
Developer-first MCP frameworks offer a different trade-off. Native client support makes it easier for technical users to get started, and server allowlisting or version pinning can reduce some supply-chain risk. Without a governance layer above those clients, it does not provide shared SCIM provisioning, a single control pane, or attributed audit records across teams.
An internally built gateway stack can address shared governance when platform engineering capacity is high. Uber built an LLM gateway for PII redaction and audit logging, an MCP gateway and registry for agent-to-tool connections, and an agent identity system extending Zero Trust infrastructure to multi-agent workflows. That illustrates the scope of the work. A well-resourced build can score well on auditability and policy enforcement, but rebuilding authentication and access plumbing can make platform engineers a bottleneck, while threat detection remains an additional problem to solve.
Running the rubric as a team process, not a solo audit
The comparison becomes useful only when the teams responsible for deployment agree on what the evidence proves. Platform engineering needs shared infrastructure that many consumers can use, while security, IT, and compliance need boundaries they can enforce and records they can use. Those needs must meet before selection hardens. A rubric gives each group a concrete way to discuss readiness instead of treating it as a general expression of confidence.
The recommended process begins with an inventory of MCP servers running on developer machines and in repositories. If the inventory misses deployments, those deployments will be left out of the decision when the platform is scored. Next, the leads from platform engineering, security, and compliance should agree on weights before they see vendor demos. IT and business stakeholders also need a shared understanding of what those requirements mean for deployment. Otherwise, a favorable technical score may leave the organizational disagreement untouched.
The proof of concept should then supply the scoring evidence. Each dimension should be judged on demonstrated, logged behavior. Teams should also confirm which specification version each platform enforces, since deployments predating the July 2026 revision may lack its authorization changes or enterprise-managed provisioning. The decisive question remains what the deployment actually enforces.
Finally, scoring should repeat on a defined cadence because tool descriptions change, server packages change hands, and the specification evolves. This turns the rubric into a shared operating practice rather than a procurement exercise filed away after purchase. Security and IT can then use evidence to resolve uncertainty and clear deployments. This process provides a practical route from “maybe someday” pilots to governed production use.