The TL;DR
MCP gateway governance controls which agents can access specific tools, what gets recorded during each call, and which policies are enforced automatically when the call happens.
-
• Access Control
Authentication proves who is calling, but authorization determines what that agent is actually allowed to do. The gateway needs clear permissions for which agents can access specific tools and actions.
-
• Auditing
Recording that a tool was called is not enough for a reliable audit trail. Every call should be tied to an identifiable agent or user so teams can trace who performed an action, when it happened, and what was accessed.
-
• Policy Enforcement
Governance works best when rules run at the moment of the tool call. Real-time policy checks can block unauthorized or risky actions before they happen instead of discovering the problem later in an audit.
MCP gateway governance is the set of controls that decide which agents can call which tools, what gets recorded when they do, and what rules run automatically at the moment of the call.
One Model Context Protocol server becomes three, then a dozen. By the time an agent has write access to the CRM, the ticketing system, and a payments API, nobody in security can give a straight answer to who’s allowed to touch what, or who signed off on it.
In September 2025, that gap stopped being theoretical. Researchers at Koi Security found a one-line backdoor inside an npm package called postmark-mcp, one of several such incidents documented publicly since. What it exposed is what the rest of this piece covers.
Why AI Agents Need a Different Governance Model
Every agent connected directly to more than one MCP server manages its own credentials, permission checks, and blind spots. With N agents and M tools, that’s N times M places for something to go wrong.
An MCP gateway collapses that math to N plus M by putting one control point between every agent and every tool. That reframing is what makes governance possible. A team can’t consistently enforce a rule across a thousand scattered connections, but it can enforce one rule at the single point everything has to pass through.
Koi Security’s backdoor is the clearest illustration of what happens without that control point. The postmark-mcp package had shipped fifteen clean versions before an attacker added a single line of code that copied every outgoing email to an outside address. It behaved normally long enough to build trust, then quietly changed. By Koi’s own estimate, roughly 300 organizations were running the infected server in production at the time, based on about 20 percent of its weekly downloads translating to active use.
Nobody reviewed the change. The agent using the tool never checked where its instructions came from. It just followed them.
A developer writes and reviews the code behind a normal API request. An MCP tool call runs because a model decided, at runtime, that a tool looked right for the job. That skips the review step entirely.
No firewall catches that. The agent making the call is authorized. It’s simply acting on instructions nobody vetted.
Attackers exploit exactly this. Tool poisoning hides adversarial instructions inside a tool’s description, the text a model reads before deciding how to use it. Elastic Security Labs demonstrated the pattern with a poisoned “daily quote” tool that steered a model into leaking an entire message history through an approved email tool. Most clients only show a user the first line of that description.
The Growth Behind the Risk
The scale isn’t hypothetical. Anthropic’s December 2025 announcement, the one that donated MCP to the Linux Foundation’s new Agentic AI Foundation, reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads.
Teams almost always start small, often with a handful of common servers like GitHub, Slack, or a ticketing system, and grow from there. Each new one is a new place credentials and blind spots can pile up.
Access Control: Agent Authentication and Authorization
Access control picks up where authentication stops. It decides what a caller may do once its identity is confirmed.
What the Spec Handles, and What It Leaves to You
MCP’s authorization model has moved fast. The March 2025 revision set OAuth 2.1 as the baseline, authorization-code flow with PKCE, no implicit grant, no bearer tokens outside TLS. The June 2025 revision went further and formally split the roles. MCP servers became pure OAuth 2.0 Resource Servers, validating tokens rather than issuing them, and Protected Resource Metadata under RFC 9728 became mandatory so a client always knows which authorization server to trust.
The specification in force today, published November 25, 2025, tightened things further still. It introduced Client ID Metadata Documents as the preferred way for a client to register itself, and it banned the plain PKCE method outright. S256 is now the only accepted method, part of a broader wave of security hardening that also includes the NSA’s own MCP guidance, published roughly six months later in May 2026. That’s three authorization overhauls in under a year, a pace the protocol has kept up on every other front as well.
None of that decides what a caller can do once authenticated, though. The spec proves identity. Authorization is left to whoever builds the gateway.
Three Practices Worth Building In
- Action-level roles, not toolkit-level roles: A role that can open a pull request shouldn’t automatically be able to delete a repository just because both actions live on the same server.
- On-behalf-of token propagation: A gateway that swaps in its own service account can only log “the gateway did this.” One that passes the calling user’s identity downstream can log who actually did it.
- Least privilege by default: Every credential an agent holds can leak through a prompt, a log line, or a commit. Narrow scopes and automatic rotation limit the damage.
How to Evaluate Access Control in a Gateway
The real question, for MCP360 or any other gateway, is whether it enforces access at the level of a single tool call or only a whole server connection.
Ask for a concrete example, one blocked action next to one allowed action on the same server. If the answer only toggles access to the entire connection, the enforcement is coarser than it sounds.
Auditing: What a Defensible Log Actually Contains
Knowing who’s authorized answers half the problem. Proving what happened afterward is the other half. A log that only shows a tool was called won’t survive an audit.
A defensible log answers five things for every call.
- Who authorized the call
- What was requested
- What came back
- Whether the call was allowed or denied
- Which policy made that decision
What SOC 2 Auditors Actually Test For
SOC 2’s CC6 criteria cover access controls, meaning enforced multi-factor authentication, role-based access, and scheduled access reviews. Data from SOC 2 auditor networks shows CC6 drawing more exceptions than any other criteria series, usually from undated reviews and slow deprovisioning.
CC7 covers system operations. It requires centralized log monitoring and a tested incident response plan. A gateway that can’t produce a structured, per-call log with an identity attached fails both before an auditor looks at anything else.
What the EU AI Act Requires, and When
Article 12 requires high-risk AI systems to automatically record events over their lifetime, covering risk situations, post-market monitoring, and operational monitoring. Articles 19 and 26 set a six-month retention floor for those records.
The timeline already moved once. Standalone Annex III high-risk obligations were originally set for August 2, 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on July 27, 2026, and pushed that deadline to December 2, 2027. Annex I embedded systems follow in August 2028.
Article 50 transparency duties mostly still apply from August 2, 2026 on the original schedule. The exception is Article 50(2)’s watermarking rule for legacy systems, pushed to December 2, 2026.
Penalties don’t change once the obligations apply. They stay at up to 15 million euros or 3 percent of worldwide annual turnover, whichever is higher.
A later deadline doesn’t make logging optional to plan for. It gives teams time to build it properly instead of bolting it on at the end.
Policy Enforcement: Turning Rules Into Runtime Behavior
Access control decides who can call a tool. Auditing records what happened. Policy enforcement sits between the two, deciding what happens the moment someone tries.
Rate limiting caps the damage from a runaway agent loop, whatever the cause. Circuit breakers halt one misbehaving tool connection without taking down every other integration, a control IBM’s ContextForge gateway added in its 1.0 release candidate. Data masking at the boundary strips sensitive fields from a tool’s response before it reaches the model. Policy-as-code engines, like Cedar or Open Policy Agent, let a rule change ship without a redeploy.
A rule enforced at the point of the call stops today’s mistake, not last week’s. Even the best policy won’t catch everything, though.
Common MCP Gateway Security Risks
Even a well-timed policy doesn’t stop every failure. MCP security in practice comes down to three recurring failure patterns, not an exhaustive list of exotic attacks.
- Tool poisoning: Adversarial instructions get hidden inside a tool’s description, the text a model reads before using it. Most clients only show the first line, so the rest stays invisible.
- Rug pull attacks: Most MCP clients approve a tool once and never check it again. A server can ship clean code at onboarding, then quietly change what a tool does later, often without changing its name.
- Credential sprawl, and what postmark-mcp shows: Every stored API key or OAuth token is one more place a secret can leak through a prompt, a log, or a commit. The postmark-mcp incident shows how little sophistication that takes. Koi Security’s own research puts the backdoor live for about a week, from its September 17, 2025 release to when Koi caught it on September 25, by which point the package had logged more than 1,600 downloads.
A gateway can’t stop a compromised package from existing. One that pins tool hashes and alerts on any change can stop a backdoor like this before it reaches production.
Where the Three Pillars Meet Compliance
Access control, auditing, and policy enforcement map onto the same criteria auditors already test for.
| Pillar | SOC 2 Mapping | EU AI Act Mapping |
|---|---|---|
| Access Control | CC6, logical access, MFA, role-based access, access reviews | Article 15, resilience against unauthorized changes to a system’s use or performance |
| Auditing | CC7, monitoring, incident response, breach detection | Article 12, automatic event logging, plus Articles 19 and 26, six-month retention floor |
| Policy Enforcement | CC8, change management, and CC9, vendor and third-party risk | Article 9, continuous risk management across the system’s lifecycle |
A gateway built to satisfy CC6 and CC7 is already producing most of the evidence an EU AI Act conformity assessment will ask for later.
How to Evaluate MCP Gateway Governance
Knowing what the frameworks require is one part of the job. Confirming a gateway delivers it is the other. The same five questions separate a governance-capable gateway from a proxy wearing a governance label, whatever platform is on the table.
- Action level or toolkit level? Ask for one blocked action next to one allowed action on the same server.
- Attributed identity or shared account? Request a sample log entry. If every row says “gateway,” on-behalf-of propagation isn’t implemented.
- Redeploy needed for policy changes? A rule that needs new code before it changes is a rule nobody updates often.
- Tool-change detection? Ask whether the gateway hashes tool definitions and alerts on change, the control that would have flagged postmark-mcp early.
- Current certifications? MCP360 holds SOC 2 Type II, GDPR, and ISO 27001 compliance. Whichever gateway you’re evaluating, including this one, ask for the audit date and the auditor’s name, not just the badge.
Five clear answers to those questions carry more weight than any certification badge on a pricing page.
Frequently Asked Questions
What is an MCP gateway?
An MCP gateway is a single control point that sits between AI agents and the MCP servers they connect to. Instead of every agent managing its own direct connections to dozens of tools, all traffic routes through the gateway, which handles authentication, records what happened, and enforces rules before a call reaches the backend system. This collapses what would otherwise be many separate connection points into one governed layer.
What is role-based access control (RBAC)?
Role-based access control, or RBAC, restricts system access based on a user’s or agent’s assigned role rather than granting permissions individually. In an MCP gateway, action-level RBAC means a role that can open a pull request on a server should not automatically inherit the ability to delete a repository on that same server. Real governance requires gating individual tool calls, not entire toolkit-level connections.
Why does MCP gateway governance need access control, auditing, and policy enforcement instead of just authentication?
Authentication only confirms who is calling. It does not decide what they are allowed to do, prove what happened afterward, or stop a harmful call before it executes. Access control, auditing, and policy enforcement are three separate mechanisms that have to work together at the gateway layer. A platform like MCP360 is one example built around this distinction, though any governance-capable gateway needs all three, not authentication alone.
What is on-behalf-of (OBO) token propagation and why does it matter for AI agent audit logs?
On-behalf-of, or OBO, token propagation means a gateway passes the calling user’s actual identity downstream instead of substituting its own service account for every request. Without it, an audit log can only say the gateway made a call, not who authorized it. When evaluating a gateway such as MCP360 or a competitor, request a sample log entry. If every row shows a shared account, OBO propagation is not implemented.
Does the EU AI Act apply to AI agents using MCP servers?
It can, depending on the use case. The EU AI Act’s high-risk provisions cover systems used in credit decisions, hiring, or healthcare, and an AI agent performing those functions through MCP servers falls under Article 12’s logging requirements. Enforcement begins August 2, 2026, with penalties reaching 15 million euros or 3 percent of worldwide turnover. A proposed delay to 2027 has not been adopted, so the 2026 deadline still applies.
How does SOC 2 map to MCP gateway access control and audit logging?
SOC 2’s CC6 criteria cover logical access controls such as MFA, RBAC, and periodic access reviews, while CC7 covers system monitoring and incident response, both of which a governed MCP gateway directly supports. A gateway producing structured, attributed logs is already generating most of the evidence CC6 and CC7 require. MCP360 states on its own site that it holds SOC 2 Type II certification, though any vendor’s audit date should be verified directly.
What was the postmark-mcp incident and what does it show about MCP security?
In September 2025, a malicious npm package called postmark-mcp was found quietly BCC’ing every outgoing email to an external address. The package behaved normally for fifteen published versions before the backdoor shipped, and it had already been downloaded over 1,600 times before researchers caught it. It shows MCP security risk often comes from supply chain trust rather than a live exploit, which gateway-level tool-change detection can catch early.
What questions should I ask before choosing an MCP gateway for governance?
Ask whether authorization operates at the individual action level or only the toolkit level, whether audit logs carry an attributed identity instead of a shared account, and whether policy changes take effect without a code redeploy. Also confirm the gateway detects when a previously approved tool definition changes. Whether evaluating MCP360 or another platform, current compliance certifications should be verified directly with the vendor.
Future of MCP Gateway Governance
MCP’s authorization model keeps moving. Client ID metadata documents and clearer server-side authorization management are both under active discussion. As agents start delegating to other agents over protocols like A2A, governance grows to cover which agents can hand off work to each other, not just which tools they can call, a trust boundary that signed Agent Cards are built to close.
The wider trend points toward federated governance. Several gateway instances, one per business unit or region, tied together by shared policy and audit standards, solve for data residency without forcing every team onto identical infrastructure.
Article by
MitaliAI & Automation | Content Writer
Mitali is a content writer covering AI agents, automation, and no-code tools. Her writing spans the AI landscape, from support and sales automation to MCP integrations and agent workflows, with a focus on practical business use.
