Why you need a kill switch for your MCP and AI gateways

An agent starts making unexpected calls through an MCP server your team approved six weeks ago. Maybe a dependency changed underneath it that exposes you to a potential security liability. Maybe tool calls are being routed to a client that is not authorized by the organization. Maybe it is behaving exactly as configured, and the configuration was wrong. Your logs are filling with calls you can’t explain, and the person who has to decide what happens next is whoever owns security, not whoever installed the server.

The question in the room is not one of architecture. It is: what do I stop, right now, and how do I know it stopped?

A growing number of organizations have put an MCP gateway in front of their agents’ tools and an AI gateway in front of their models, and every call now passes through the infrastructure they operate. For those teams the question has changed. It is no longer “can we see it.” It is “when something goes wrong, can we shut it off, and can we tell that we did.”

That’s why we’ve released the killswitch in Stacklok Enterprise. 

A gateway gives you a chokepoint, but it doesn’t automatically give you a plug to pull. 

A gateway is only useful in an incident if someone can shut it down intentionally  Many teams discover the gap the hard way: the gateway is running, traffic is flowing through it, and the only way to stop a misbehaving agent is to find the engineer who set it up, roll back a config, and wait. In the meantime the agent keeps calling your ticketing system, your data warehouse, your code host, driving up token costs and exhausting and causing resource contention across shared tools.

That is not a kill switch. That is a change request with a sense of urgency (and a frustrated engineer). 

Introducing the kill switch:

Stacklok Enterprise now gives administrators a kill switch for each gateway in the platform’s admin settings. Turning it off disconnects that gateway from data-plane traffic.

• The MCP gateway. Agents can no longer reach any MCP server behind it. Tool calls that were working a moment earlier are refused, including in sessions that are already running.
• The AI gateway. Model requests routed through it stop being served, so agents can no longer get responses from the models behind it.

In practice, the effect shows up within seconds. The refusal is explicit. A blocked call doesn’t time out or fail with a generic error. The gateway responds that it “has been administratively disconnected and is not currently serving data-plane traffic,” with the error code administratively_disconnected. Anyone looking at the failure, human or agent, can tell it was a decision and not an outage. With a killswitch, an admin’s life looks a lot different then waiting and doing investigative work for an hour, seeing who deployed the server, and then back tracking it. 

It is also reversible. Turn the gateway back on and traffic resumes. In our test, the same agent session picked up where it left off, with no reconfiguration on the client side.


Why this matters to the people accountable for security

Developers adopted MCP because it made them faster and gave their agents more context to do more work. Security and platform leaders inherited the consequences: servers nobody registered, tokens with too much reach, and no consistent place to see or stop any of it. A gateway closes the visibility gap, but a kill switch closes the authority gap.

The plug sits with administrators. The action lives in the platform’s admin settings, not in a developer’s config file. Security doesn’t have to locate whoever wired up a server and ask them to undo it. You figuratively pull the plug, and it stops. 

It covers both halves of what an agent does. An agent acts through tools and decides through a model. Cutting the MCP gateway stops it from acting on your systems. Cutting the AI gateway stops it from getting answers at all. Having both means you can choose how much to stop.

You can tell it worked. A named, typed refusal is distinguishable from every other kind of failure. That is the difference between “I think we stopped it” and something you can point to afterward.

Adoption and control stop being a trade-off. Governance often slows AI adoption because the only safe answer to “can we connect this” is “not yet.” When you know you can disconnect a gateway in seconds and bring it back just as fast, approving the next connection becomes a smaller decision.

Why it has to run in your environment

A kill switch that lives in a vendor’s SaaS control plane is a kill switch with a support ticket in front of it. If you have to pull the plug and it runs in someone else’s environment, your incident timeline includes their response time. When you self-host, you control it end-to-end. 

Stacklok Enterprise is self-hosted and Kubernetes-native. The gateways and the switch that disconnects them run in the infrastructure you operate, and access to the gateways is tied to the identity provider you already run. Your data stays in your environment, and the decision to pull the plug is yours, on your schedule.

The question to ask any gateway vendor

Don’t ask “do you have a kill switch.” Ask instead:

• If an agent started behaving badly this afternoon, what single action stops its tool access, and what stops its model access?
• How long does that take to reach traffic that is already in flight?
• What does a blocked agent actually receive, and could I tell it apart from an outage?
• Where does that control run: in my environment, or in yours?

A vendor who answers “there’s a button” without addressing those has told you they don’t understand the question.

Ready to start?

Stacklok enterprise now includes the killswitch. Connect with our technical team, and see how the platform works today.