An agent kill switch isn’t the (full) solution

It seems like a pretty popular answer to the question of how we’ll protect ourselves from rogue AI agents is to build kill switches.

Governments are rushing to pass laws to enforce kill switches, everywhere from the US to Europe, as panic starts to circulate about the lack of control frontier AI model providers have.

Security companies are also getting in on the act. Okta announced an agent kill switch as part of its Agent Gateway offering. Straiker’s “Agentic Kill Switch” enables developers to revoke tools from an agent, suspend agent sessions, and shut down an entire fleet of agents. The basic idea is that if we can kill an agent, we can prevent it from turning into an agent of chaos.

I have a slightly different opinion about it. I think agent kill switches are being born from panic rather than actual usefulness. Although implausible to actually function on a government/frontier model company playing field, I can see some sort of policy helping assuage the fears of the public at least, if they can agree on who should have control of the button and under what settings it can be used (yea, very likely).

However, implementing something like this within a company setting is, with current practices, next to impossible.

A kill switch is a reactive response, and to respond, you have to both know that something went wrong and know exactly which agent did it. But how do you know an agent went rogue?

Let’s work through a basic scenario in two contexts.

Rogue is usually boring

In the real world, rogue agents tend to be boring:

• The agent is using a model it wasn’t supposed to use.
• The agent accessed a database it wasn’t supposed to access.
• The agent’s token spend went through the roof at 3am.

In each case, if you are the one paying attention to the agent, you’d think something had gone awry, but none of these look like an attack while it’s happening and none require malice. For example, if you have a team running five agents, with a few using Claude Code or Codex and the rest autonomous on a VM and Mac mini, one might get stuck in a loop around 3am and start calling an expensive model over and over while also starting to query the customer database. Nothing actually breaks and so it ends up running for several hours before the "oh sh*t" moment you get the next morning.

Five agents + one key

Most teams set up agent access like this: One person grabs a provider API key and passes it around. The key goes in all kinds of env files: your developers’ laptops for Claude Code and other projects, the VM and Mac mini for autonomous agents, and CI jobs and scripts.

To say this is hard to keep track of is an understatement. I've heard way too many stories about keys just being put in a Google Sheets file, or shared through Slack, or getting leaked on GitHub. If this is you, don't worry, it's way more common than you might think 😅

But in 99% of the cases I've seen, there's no real list of who has what key for which purpose. Even if they started off with one, the key's now been copied into so many places it's obsolete. And each key is racking up its own bill with no real way to track what it's being used for, or who has access to it.

The other issue is that this is a flat network. Each agent can reach way more than it needs, everything from the backend prod database to your HR file store and anything else you've given it. All agents making requests do so with the same key. You can't tell which agent is accessing what. It all looks the same.

It’s not till the next morning, when someone sees the spend, that an issue is raised, and even then, you have to figure out which of the five agents is the culprit, and ask around. Did Edward leave something on again? Did he mean to spend $500 in Anthropic credits, or was that a mistake?

If it was a mistake, the only way to really shut it down is to revoke the shared key. Which also shuts down your four other agents. Which also breaks dozens of team and agent pipelines. Which means now you have to get a new key and spread it around to anyone who needs it, again. And the money’s already spent, the damage is already done.

Five agents + five identities

Let’s run through the same situation but in a slightly different setup. Instead of agents accessing resources like CEOs, make them more like consultants: give them their own identity within your network. So, in your Claude Code and Codex pipeline, the agent identity is tied to your developer's identity which is set using whatever identity provider you normally use, like Google SSO or Okta. For the autonomous agents, each has its own peer identity, which means it can be put in groups and tracked individually.

You might be thinking that that sounds like a lot of API keys to keep track of. A different key for every agent? What's stopping the same spaghetti mess of credentials from happening again?

This is the best part: NO MORE API KEYS.

Instead of having the base URL + API key for each provider, you simply set the base URL to your private endpoint. That endpoint proxies all requests and scrubs off all the auth headers the client puts on those requests and injects the key that the server has on your provider. No API keys passed around, and if you need to rotate, you only need to do it in one place.

Plus, because everything is identity-based, this means you can set different token and spend limits on both a user and group level, plus an allowlist of models, AND you can set per-resource restrictions, so policies can ensure that any agents you don't want to reach your prod database don't.

Lastly, log every request. Log who made it, with which identity, on which provider, and with which model and how many tokens and dollars were used. This is done by the proxy, regardless of any logging setting. This way, management can see usage, per user or group and per provider and model.

Now, we don't need to wonder if Edward accidentally spent $500 on Anthropic, we can literally just look into the dashboard and see. And if we want to cut him off, we simply remove him from a group or disable a policy, and bam, no more vibe coding for Edward.

But how?

"Victoria," you might be saying right now, "this seems like a lot to build. Isn't there an open source project that will do all this for me?"

YES THERE IS!!!!

Agent Network is indeed free and open source.

You can find the docs here: https://docs.netbird.io/agent-network

But even if you didn't want to use our awesome open source solution, there are still some ways you can implement identity-based agent access in your team.

1. Create a workspace or project for each team or agent.
2. For Anthropic, set up API keys tied to a workspace. Use the monthly spend limit per workspace to control costs.
3. For OpenAI, set up projects with their own service accounts and API keys. Tie each project to a specific set of models.
4. Set up an LLM gateway like LiteLLM in front of your provider. Set it up with a virtual key per user or team, with a max budget and a list of models you want to use. The spend is tracked per key (in dollars).
5. Make your network "deny by default" so agents only reach resources they actually need.
6. Start listing who owns what key and what it's used for.

Yes, this still puts a key on the client side. But it lets you see which key is used on the server-side, and lets you set limits and control access, which is at least a start.

Kill switches aren't useless

Kill switches aren’t useless. But you can’t kill what you can’t see. With per-agent identity, stopping one agent is a matter of a policy or group update, without killing the entire fleet.

None of this will stop an agent from going rogue, but it does limit the damage and makes it easier for a human to understand what happened.

The network is just one layer. There are so many more layers of security. So many more.

And if the latest security incidents are any indication, we're gonna need all the layers we can get.