Why an MCP Gateway Is Not Governance

Recap of the July 22 session with Kevin Paige, Field CISO at C1, and Paul Webber, Principal Industry Analyst at SACR. Watch the full recording here.

Most teams securing AI agents start the same way: stand up an MCP gateway, route the traffic through it, call it handled. On July 22, C1 Field CISO Kevin Paige sat down with Paul Webber, Principal Industry Analyst at Software Analyst Cyber Research, to take that assumption apart.

The thesis they kept returning to is simple. A gateway enforces policy on the calls passing through it. Governance answers a deeper set of questions: who or what was entitled to that tool, who approved it, what scope the access carries, how long it lasts, and how you pull it back. A gateway answers "should this call pass right now." No amount of inline enforcement answers the rest.

Here's what the conversation covered.

Why this matters now#

Enterprises have moved from agent pilots to agent operations over the past year, and in most organizations the guardrails have not kept pace. Webber framed the shift plainly: once agents can take action rather than just suggest or summarize, identity becomes the control plane. You are no longer only protecting data. You are governing what autonomous and semi-autonomous actors are allowed to do, on whose behalf, with what scope, and for how long.

Data from the C1 Future of Identity report backed up the urgency. 95% of organizations report AI agents already performing IT or security tasks autonomously, while only a fraction maintain continuous policy enforcement across them. Webber flagged one finding as especially telling: agent visibility actually declined from the previous year's report. The attack surface is expanding faster than the ability to see it.

Where a gateway goes blind#

Paige walked through four failure modes where teams confuse routing with governance:

1. Shadow agents. Agents operating outside the gateway entirely, through developer tools, direct API calls, and unmanaged services. They never touch your control point. The gateway doesn't know they exist.
2. No session context. A gateway sees a call, not the chain behind it. The link between user, agent ownership, and action is broken, so attribution fails exactly when you need it.
3. No kill switch. Blocking a future action is not the same as revoking in-flight access. Until you revoke the agent's delegations and tokens, it keeps acting with rights you think you've removed.
4. The audit gap. Logs tell you what happened. They don't tell you who approved the access, why it exists, or when it should have expired.

Webber drew a historical parallel that landed: trusted, ubiquitous tooling has been the preferred attack path before, from the SolarWinds compromise onward. Widely deployed, overly trusted infrastructure with far-reaching access is exactly what attackers look for. MCP gateways fit the profile.

SACR's four MCP risk layers#

Webber then laid out SACR's research framework, which treats agents as first-class identities in their own right. They reason, call tools, and chain actions together, so the problem space is delegated authority plus runtime behavior. Within MCP specifically, SACR identifies four risk layers:

1. Chain integrity. Untrusted MCP servers, poisoned tools, malicious connectors. The question: which servers are actually verified, and who verifies updates? A gateway only sees calls, never who changed the system behind them.
2. Communication security. Weak authentication, unprotected transport, exposed local deployments, data leakage.
3. Credential management. Long-lived secrets and shared accounts. Proper governance asks whether credentials are short-lived and task-scoped.
4. Authorization and revocation. The layer buyers consistently underestimate. Teams invest heavily in authentication, then discover that authorization granularity and revocation are what actually bite them.

What good governance looks like#

Asked for C1's view of the target state, Paige laid out the architecture:

• An identity-aware proxy, where every tool call is authenticated and permission-checked with full identity context: which user, which agent, on whose behalf, under which approval, and why.
• First-class revocation. A kill switch at the agent level that revokes in-flight access and the rights underneath it, not just future calls.
• Credential vaulting. Service credentials never live on endpoints, laptops, or config files. Short-lived tokens issued from a vault replace static secrets.
• Scope minimization. Agents get the smallest permission set that lets them do the job.
• Audit that answers the real question. Not just what the agent reached, but who signed it off, what scope was granted, and why the access was still valid at the time.

We've written about these primitives in more depth in four things your identity stack needs before agents hit production.

He also gave teams a place to start: inventory first, because you can't govern what you haven't discovered. Then attribution, so every call ties back to an agent, a session, and an approval. Then replace standing credentials with vaulted, short-lived, scoped tokens. Then build the lifecycle: requests, approvals, reviews, revocation. The through line is treating MCP governance as part of identity governance, owned by identity and security teams, rather than as a network or API security problem.

Where this is heading#

The session closed with predictions for how agent governance matures. The leaders will be the organizations governing autonomous actors continuously, at machine speed, instead of relying on the periodic reviews most teams run today. Agent access management becomes a first-class identity discipline rather than a side project, and security teams shift from manual execution toward oversight.

Webber's closing line summed up the whole hour: a gateway decides whether a call can pass. True governance decides whether the agent should have had the right to make that call in the first place, and can take that right away again.

Go deeper:

• Watch the full webinar recording
• Read the Agentic Adaptation Playbook
• Join us at C1 Transform, our inaugural conference for security, technology, and identity leaders, October 6 in San Francisco