ServiceNow shipped the control we keep asking about
ServiceNow has put a Kill Switch into AI Control Tower v2.0, with more detail than these features usually carry. A September 2026 post to the ServiceNow Community, written by a badged ServiceNow employee, calls it verified, auditable containment for compromised or malicious agents, and says it orchestrates credential revocation across ServiceNow agents, Okta, GCP and AWS. The containment does not stop at the ServiceNow boundary, and that is the part worth arguing about.
We have said more than once that an agent kill switch usually amounts to someone pointing at a settings page nobody has tested, and that a pause control only counts with a named owner and a written resume record. This is the first vendor description that answers the shape of that complaint, which earns a closer reading rather than applause. We took the same line when Experian said it could kill its own agents inside a customer's instance.
The same post lists the Kill Switch alongside runtime agent evaluations scored by an LLM-as-a-judge and Veza-derived agent maps. It does not sort any of that into generally available and preview, so none of it belongs in a containment procedure yet.
Three external systems, three ways it can half-fail
Stopping an agent inside one platform is a problem ServiceNow controls end to end. It owns the runtime, the credential store and the audit log, and decides what stopped means. Revoking credentials across Okta, GCP and AWS sits in a different class, because three of those four legs run in systems ServiceNow can only ask.
The post does not describe error handling. Our read is that an integration spanning four control planes has to survive partial failure as the normal case. An Okta call can be rate limited during the same incident that made someone reach for the switch, and a revoked GCP key does nothing about a token issued minutes earlier.
The first question for a ServiceNow account team is what the Kill Switch does when one leg fails. Rolling the other three back, leaving them revoked and raising an incident, and reporting success because the requests went out are three different behaviours. The difference decides whether anyone can say the agent was contained.
Verified has to mean confirmed by the other system
Verified is the word doing the most work there. There is a wide gap between a system that sends a revocation request and logs that it sent one, and a system that reads back from Okta, GCP and AWS to confirm the credential no longer works. Both get written up in a feature list the same way.
An auditor will want the second one. The evidence that matters after an incident is a record showing the credential was live, that revocation came back confirmed from the system that issued it, and that no successful call followed. A log showing ServiceNow asked Okta to revoke proves ServiceNow did its part and nothing about the agent. The same problem turns up whenever a service identity spans more than one platform.
Pulling credentials does not stop work already in flight
Revoking credentials stops the next call. It does not settle what happens to work the agent had already started. An agent partway through a change request, or one that had written half a set of updates across a CMDB and an external ticket, leaves records in a state nobody designed.
The post does not cover that, and an operations lead has to answer it before trusting the switch. Which records were touched, which were left mid-update, and who reconciles them are the questions that fill the hour after containment. A pause control needs a named owner and a written resume record for exactly this reason. Containment and cleanup are separate jobs, and the Kill Switch covers the first.
Who can pull it, and how you would rehearse it
The other half of our complaint concerns who holds the control. Revoking credentials across four systems is among the most destructive actions an admin can take, and the people who need it during an incident are not always platform admins. Ask which role can trigger it, whether that role is separate from the one that builds and publishes agents, and whether a second approver is needed at three in the morning.
Then ask how anyone would test it. A kill switch nobody has fired is a claim rather than a control. Testing this one means a sub-production instance with live Okta, GCP and AWS integrations wired in, because the external calls are the parts most likely to fail and the parts a mocked test skips. That cost belongs in the implementation estimate rather than in the first thirty minutes of a platform incident.
One practical wrinkle sits in the same post. It says v2.0 arrives with a redesigned AI Native interface and that most new features are reachable only from there, so whoever reaches the switch under pressure needs access to it and practice with it.
Two vendors publishing the same agent
The Agent 365 item in the same post deserves its own look. ServiceNow describes it as "Bidirectional governance between ServiceNow and Agent 365: Stewards can publish/unpublish SN-managed agents to Agent 365". Publishing and unpublishing agents across two vendors' control planes raises a question no feature line can settle, which is which side is authoritative when the two disagree.
Ask what Agent 365 does when a steward unpublishes a ServiceNow-managed agent, and how fast. Ask the reverse for a Microsoft admin blocking that agent in Agent 365. An agent unpublished on one side and still live on the other during a containment event is the failure the Kill Switch exists to prevent, and the ServiceNow agent governance surface now answers to two consoles.
Anyone running agents in production can do one useful thing before the next release window. Write down every credential store those agents authenticate against, name the person who can revoke each one today without a ticket, and time how long each revocation takes. If the Kill Switch beats those numbers with a confirmation an auditor would accept, it has earned the name.
