How to Govern MCP Without Breaking Your Stack

Your CISO asks for a routine network discovery scan. Shadow SaaS, the usual. The report comes back with two hundred MCP endpoints. Unknown owners. Some on engineer laptops. Some hitting third-party APIs at a cadence nobody can describe. A handful are reaching production data with credentials that belong to one person, not to the company. None of them rode through the change-management queue. None of them land in the audit pipeline. They were already there before the scan started.

That scan is one of three conversations sitting on your desk this quarter, and they don't look related until you stack them.

The first is the one you expected. An engineering lead Slacks you asking permission to deploy an MCP server. Polite, scoped, on the ticket queue. This is the interaction IT teams plan for, and it's the smallest/most predictable of the three.

The second is the scan. The vibe-coded servers. Users wired up to production data systems (via LLM clients) from their laptops, using credentials they personally hold. You don't know which servers are duplicates, which third parties are legitimate, or what data is moving where. You also don't know whose name is on the audit trail, because there isn't one.

The third comes from a vendor. Their next product update requires an MCP integration to unlock the AI features your business already depends on. Saying no costs you functionality you've already paid for.

In all three, MCP is happening to your stack. Saying no doesn't stop it. It just stops you from governing it. So MCP governance isn't a question you get to defer, even though every signal in the conversation, the polite ticket, the messy scan, the vendor ultimatum, will quietly invite you to.

There's a way that doesn't require new fences.

What MCP Changes

The Doorway MCP Opens

Strip the protocol away and a Model Context Protocol (MCP) server is one basic thing: an endpoint that lets an MCP client read or invoke your tools and data, on someone's behalf. A new doorway into systems you already own, opened by a caller you didn't write, acting for a user whose name may or may not even be on the request.

That doorway opens five surfaces you've governed for years, the same ones your cyber insurance underwriter asks about, the same ones your ISO audit wants evidence on, the same ones your regulators put in writing. Just never in this shape.

The Five Surfaces You Already Govern

There's identity: whose credentials are flowing through the AI when it acts. There's authorization: which actions on which systems that identity is allowed to take. There's audit: who did what, when, with what context, and can you prove it tomorrow. There's lifecycle: how a server gets approved, retired, or rolled back without a Slack thread. And there's discovery: whether anyone in the building can tell you what's connected right now.

Read that list again. None of it is new. Your IDP answers identity. Your RBAC answers authorization. Your SIEM answers audit. Your change-management process answers lifecycle. Your CMDB answers discovery. You already run the governance framework that answers every one of these questions.

The Missing Control Plane

You just haven't pointed it at this surface yet. The gap is the absence of a control plane, not the absence of capability. The security controls already exist. The oversight mechanisms already exist. The governance practices and governance programs are documented, audited, and humming along like they have for years. What doesn't exist is the place where MCP traffic lands so those controls can see it. So MCP governance is mostly the work of pointing existing muscles at a new surface, which sounds easy until you actually try it.

The gap stays open.

The Four Traps

Faced with that gap, four responses tend to surface. Each is reasonable in a vacuum. None of them end where you want.

The DIY Trap

You know your stack. You'll just build the gateway yourself. Six months later you have a homegrown proxy, an audit trail nobody trusts, RBAC that lives in a YAML file, and one engineer who knows how the whole thing breathes. Then MCP ships a new version. FastMCP adds another capability. Your engineer is chasing feature parity in what's been called the most rapidly evolving technical space in history, on the side of a full-time job. The cost compounds. The capability doesn't.

The Catalog-and-Scan Trap

Inventory tooling is mature, so reach for it. The dashboard counts your two hundred servers and renders the entire MCP footprint in a tidy grid. Congratulations. You can see the surface now. You still cannot govern it. Visibility without control is just better-documented exposure, and the security risks the scan flagged keep accruing while the dashboard refreshes. Pretty graphs. Same exposure.

The Point-Tool Trap

Every MCP server brings its own auth model, its own log shape, its own integration story. Your SIEM team gets ten new normalizations to write. Your IDP team gets ten new tickets. Cross functional teams get pulled into ten new debates about whose internal policies apply. The governance burden grows linearly with every server you add, and the seams between them are where incidents hide.

The Shadow Trap

Don't look. The vibe-coded servers from the scan keep running. The credentials keep flowing. Nothing breaks today. The cost gets paid eventually, by someone, usually after an incident with your name in the timeline.

Four somewhat reasonable responses. Four ways the surface keeps spreading.

What Attackers Actually Do With MCP

The five surfaces tell you what to govern. The threat model tells you what happens when you don't. MCP security, at the end of the day, is mostly the security you already do, redirected at a surface where the failure modes wear new clothes, take new shapes, and slip past muscle memory before anyone notices. MCP introduces a small set of attack patterns that didn't exist in this shape before, and they're worth naming, because most of them collapse against a control plane and most of them stay live without one.

Name them.

Tool Poisoning

A tool definition is a string. The model reads the string. The string can lie. A malicious MCP server can register a tool whose name and description claim it does one thing while the underlying API call does another, or whose description carries instructions designed to manipulate model behavior the moment the tool is enumerated. The model trusts the tool definitions, the user trusts the model, and the attacker sits comfortably in the gap between those two acts of trust. A gateway that pins approved tool definitions, surfaces diffs, and logs every tool call against the registered shape neutralizes most of this. Without one, the tool definition is just whatever the server says it is on Tuesday.

Prompt Injection at the Tool Boundary

Prompt injection isn't new. MCP gives it new mouths to speak through. Any data returned from an MCP tool, a Slack message, a JIRA ticket, a database row of sensitive data, flows back into the model's context and can carry instructions the user never wrote. The classic exfiltration pattern is "read this support ticket, then send the contents to this URL." The classic privilege pattern is "now use the tool that writes to production." Audit logging at the gateway gives you the artifact to investigate after the fact. RBAC at the tool level gives you the controls to make sure the second tool was never reachable in the first place.

Malicious MCP Servers

The protocol is open. Anyone can publish a server. A user finds one on a registry, points their client at it, and the server now sees every MCP tool call that user makes through that client, plus every payload in and out. The server code is whatever its author chose to ship. Some servers are well-intentioned and abandoned. Some are deliberate. Either way, MCP interactions through that server are exfiltration channels waiting for an excuse, and the user interactions feeding them can carry sensitive operations the user didn't realize were in scope. Your existing software supply-chain controls (vetted registries, signed builds, vendor review) already know how to handle this category. They've just never been pointed at MCP.

Shadow MCP and Credential Drift

The scan from your CISO is the artifact of this one. Engineers spin up servers locally with API keys and SSH keys that belong to them, not to a service account, and they wire those servers up to internal tools and external services using credentials nobody else can see, nobody else can rotate, and nobody else even knows exist until the day they break or the day they leak. The credentials never rotate. The audit trail never exists. The server never registers anywhere. When the engineer leaves, the keys leave with them in a way that's still alive. Visibility-only tooling tells you the shape of this problem. A control plane that mandates connection-time authentication and forbids personal credentials from ever reaching production-class servers tells you the problem has a fix.

So what does the other path look like.

Six Questions, Six Answers

The other path is Horizon. We collapse the MCP surface into a single control plane your existing governance already knows how to govern. One gateway in front of every server you run, every server a vendor ships you, every server an engineer wrote on a Friday afternoon.

Six questions a CISO will ask. Six places consolidation lands.

Identity: Whose Credentials Are Calling

Horizon's first job is to enforce authentication as a connection-time check at the gateway, mandatory by default on every deployed server, with passthrough as an explicit opt-out for Hosted endpoints that own their own auth. Humans sign in through your existing IDP via SSO. Automation calls in with service accounts. The directory of record stays the directory of record.

The gateway also handles delegated authentication for downstream servers. When a request needs to reach an external MCP like Slack or GitHub, Horizon brokers that handoff through a single sign-in screen rather than forcing a separate flow per server, and for Remix servers that compose capabilities from multiple sources, that delegation becomes federated: multiple downstream auths collected into a single user pathway. Either way, the identity is something your stack already knows how to answer for. Same surface, same controls.

Authorization: Who Can Call What

Horizon's RBAC splits along two axes. There's programmatic access, who can invoke a server and which tools on that server they can reach. And there's configuration access, who can edit settings, change deployments, or alter behavior in the UI. Horizon controls both through organization roles, server access, custom server roles, and tool-level permissions. The granularity goes down to the individual tool. Map those to the roles your team already operates.

Audit: What Did They Do, and Can You Prove It

Horizon's gateway runs audit logging on every MCP tool call, scoped to the user and the session that made it. You can drill into any individual's MCP activity and see exactly which servers they reached, which tools they invoked, what the prompt or request payload contained, what the tool returned, and whether the call was accepted or rejected.

The gateway record is the audit artifact, structured and queryable end-to-end, and it's the evidence you'll reach for when a regulator or internal auditor asks about AI usage. The same record proves regulatory compliance and surfaces compliance risks in one trace, with the governance controls visible in the same surface as the activity itself.

Lifecycle: How a Server Gets Approved

Horizon makes lifecycle a workflow instead of a wiki page. A Hosted server moves from build, to preview, to a promoted deployment, with rollback as a first-class action. Each build carries logs you can debug from when something fails. External servers follow a registration lifecycle instead, where every remote MCP shows up in one catalog so platform owners can see duplicates, retire unvetted entries, and standardize on a single approved version of each connector. Remix servers inherit their lifecycle from what's upstream, with the composition itself as the approval moment. Across all three, change control stops being a meeting and starts being a deployment pattern your team can actually follow.

Coverage: Hosted, External, and Remix

Horizon offers three onramps under one umbrella. Hosted servers are your own code, built and run by Horizon from a Git repo. External servers run elsewhere (a vendor's MCP endpoint, a third-party tool, or a homegrown MCP server you host in your own VPC) and get registered into the catalog so their access is governed the same way as everything else. Remix servers compose scoped endpoints from capabilities pulled out of multiple servers. The vendor that requires MCP, the homegrown server your team wrote, and the curated subset you expose to a junior engineer all sit under the same controls.

Runtime: Where It Runs, What It Touches

Horizon handles startup, request handling, timeouts, memory, environment variables, local state, and logs as part of the runtime model. Sessions are preserved across the gateway so the protocol stays intact under the hood. You're not asked to rip and replace your runtime posture. You point it at one place.

Horizon doesn't replicate your governance stack and doesn't replace your policy regime. It sits in front of the MCP surface as the control plane, plugs into the identity stack and compliance posture you already run, and consolidates audit and lifecycle where they're easy to govern. The layer you already operate finally has something to govern.

Which raises the next question, the one you've been holding since the second paragraph of this post. Where does Horizon actually sit in the stack you already run.

Where Horizon Meets Your Stack

Picture your governance stack the way it sits today. The map below shows where Horizon meets it. Two real plugs into the tools you already run. Two places where Horizon takes governance work off your team's plate by absorbing it inside the platform.

Integration map: Horizon in your existing governance stack

Two integrations. Two consolidations.

IDP to SSO and Service Accounts

Identity flows in from the IDP you already operate. Humans through SSO. Automation through service accounts. The directory of record stays the directory of record. No second source of truth for who an MCP request belongs to.

Audit Lives in Horizon

Every MCP request, scoped to user and session and payload, sits in one queryable surface inside the platform. Your security and audit teams investigate from one place instead of scraping logs from each server, chasing down ad-hoc audit trails, or correlating findings across vendor UIs. One place, one truth. When a regulator asks, the answer is a query, not a project.

Lifecycle Stays Out of Your Way

Builds, previews, promotions, and rollbacks happen inside Horizon as a continuous workflow. Push code, Horizon builds and deploys. Your existing change calendar doesn't need a new column for "MCP servers." The lifecycle complexity stays bounded inside the platform instead of leaking into your team's process.

Compliance to Policy Enforcement

Your compliance team, hopefully, already wrote the policy. Data residency. Retention windows. Classification rules. The controls your cyber insurance underwriter required. The access management your ISO audit asked for. The evidence trails your regulators expect. Horizon's RBAC and access controls get configured to match what they wrote. Enforcement happens at the gateway. The policy authors stay the policy authors. Regulatory requirements stop being a quarterly scramble and start being a configuration.

Two clean plugs and two consolidations. The MCP surface becomes governable without significantly growing your tool count or your meeting count.

Whether Horizon fits is the easy half. The harder half is how you'd evaluate any platform claiming to sit in this spot, Horizon included.

The Platform That Earns Its Place

The Vendor Meeting Test

The evaluation looks like a vendor meeting where you stop asking what the platform does and start asking where it sits. You walk in with the integration map in your head. You point at the IDP and the policy doc and ask the vendor to draw their lines into yours. The platforms that earn the spot draw two clean lines and tell you the rest stays inside. The ones that don't draw a third box and ask you to staff it.

What You're Actually Buying

You don't need a platform that promises to solve AI governance. You need a platform that respects the governance you already built, and gives it the control plane MCP currently lacks. The difference shows up on day ninety, when one platform has quietly absorbed your MCP traffic into the audit and RBAC posture you already run, and the other platform has become the third box on your team's diagram.

The Questions That Filter Platforms

If you're vetting any other platform claiming to do this, the questions are the same. Does it plug into your identity stack? Does its audit logging land somewhere your team can actually investigate from? Does it consolidate the surface or just add another to it? Does it cover hosted, external, and remix servers under one set of controls, or does it govern one and leave the other two to you?

Once that surface is consolidated and observable, something else becomes possible. Every MCP request is a record of a decision an AI made on someone's behalf. Aggregated, those MCP tool calls become a corpus your security team, your audit teams, and your compliance team can finally reason over together. One place. One truth. That record, queryable end-to-end and sitting where everyone can pull from it without asking permission, becomes the foundation for things your stack has never had before.