You can't kill what you can't name
By Saakshya · Published 19 September 2026 · Updated 12 October 2026 · 5 min read
First published on LinkedIn. Rewritten for this site.

In short
In a Harness report released in September 2026, 76% of respondents believed they could disable a misbehaving agent within 15 minutes, but only 33% had an instant kill switch. We think the gap starts earlier than the switch. An agent that shares a key with nine others has no name to revoke.
On this page
Read this first
Picture a platform team that keeps its agent list in a spreadsheet. Each row has a name, an owner and a rough purpose. It's tidy and it's updated every month or so. Then one Thursday evening someone from security says an agent is sending odd requests to a customer database, and asks the team to switch it off.
They look at the spreadsheet. The agent is in there, sort of. There's a row called "reporting helper". But the helper runs as three instances, and all of them, plus six other agents, use one service key. Revoking the key stops nine agents. Leaving it means the odd requests carry on.
That's a made-up evening. It's a fair picture, though, of a number Harness published.
What the survey says
Harness released a report on 10 September 2026 called The State of Agent DLC 2026. It surveyed 700 technology professionals at large companies in the US, UK, France, Germany and India, with Sapio Research running the fieldwork in July. We read the press release on 12 October 2026 and haven't seen the full data.
Two of its pairs of figures stood out to us. 77% said they were confident they had a complete inventory of every agent, MCP server and model in their environment, and only 44% ran active discovery tooling to verify it. And 76% believed they could disable a misbehaving agent in under 15 minutes, while 33% had an instant kill switch in place.
The report also says roughly seven in eight respondents had at least one tangible agent-related issue this year. That's their wording, so we've kept to it.
Not a governance gap
The easy reading is that teams are overconfident and need better governance. Maybe. But we think the problem is plainer than that. You can't switch off a thing you can't name.
An inventory is a list people write down. It's built from logs, configuration files and whatever someone remembered to register. An agent that starts fast, on a shared key, in a container that lasts ten minutes, may never get a row. It can still do whatever the key allows.
A kill switch asks for more. It needs something to revoke. If ten agents share a credential, revoking one means revoking ten, and so the practical choice on Thursday evening is between a blunt switch and none. That's why an inventory is cheap and a working kill switch is expensive. The list needs a spreadsheet. The switch needs each agent to carry a credential that is its own.
We looked at the same shape in Read-only is a permission, where researchers couldn't point at one agent among thousands. And Switch it off today covers the separate problem of making every service notice a withdrawal. This piece is about the step before both: having a name to withdraw.
What a real switch needs
Three things, as we see it.
One agent, one credential. It's short-lived, issued when the agent starts, and tied to that agent's own entry, so there's a single answer to "which one is this?"
One place to revoke. Every service that accepts the credential checks it there, so revoking one agent stops its calls downstream within seconds, with nobody else affected.
And a drill. Create a test agent, let it make a few calls, revoke it, and time how long each service takes to stop honouring it. The slowest one is your response time. It'll probably be longer than 15 minutes the first time, and finding that out on a quiet afternoon is the point.
Read this diagram as text
- Issue: someone vouches for the agent and sets what it is allowed to do.
- Register: the agent is entered on the public register.
- Present: when the agent needs something, it shows its permission to an office.
- Check: the office looks the permission up on the register before it says yes.
- Revoke: when the permission should end, it is switched off, and anyone checking afterwards will see that.
- Then the cycle can start again with a new permission.
The picture shows the life of one permission. The step that matters here is the last one: switching it off the day it should be. That step only works if the permission belonged to one agent in the first place.
We aren't describing how a withdrawal gets published or checked. That's for the open specification. The requirement stands without it.
The law is also asking
India's Digital Personal Data Protection Act 2023 is the law we have in mind, and this is our reading, not advice. Section 8(5) requires a data fiduciary to take reasonable security safeguards against a personal data breach. Section 8(6) requires it to tell the Data Protection Board and each affected person. Under Rule 7 of the 2025 Rules, as reproduced on dpdpa.com, the Board gets a description of the breach without delay and detailed information within 72 hours of the fiduciary becoming aware of it.
If you can't say which agent did something, the 72 hours get spent finding out. We couldn't open the Gazette copy of the Rules, so the wording is from that reproduction. Please check it. Taxmann reports that section 8 comes into force on 13 May 2027.
What we don't know
We don't know what "instant" meant to the people who answered. The press release uses it, and we haven't seen the question wording. Some may have counted a manual process. Others may have counted an automatic one.
We don't know how many of the 33% could stop one agent without stopping its neighbours. That's the part we care about, and the release doesn't say.
And we haven't decided how short a short-lived credential should be. Minutes make revocation easier and renewal busier.
So here's the question. Could you revoke one agent's access in the next five minutes without shutting anything else down?
Questions people ask
- What is the difference between an agent inventory and a kill switch?
- An inventory lists the agents you think you have. A kill switch stops one of them. The first is a spreadsheet and takes an afternoon. The second needs a credential that belongs to that agent alone, plus a place every service checks, which takes real engineering. Having the list doesn't mean you can act on it.
- How should a team test whether it can switch an agent off?
- Run a drill. Create a test agent, let it make a few calls, revoke it, then time how long each service takes to stop honouring it. The slowest service sets your real response time. That measured number is worth more than anyone's belief about how fast they could do it.
Share this piece