A real kill switch lives outside the agent’s reasoning. One call, and every subsequent decision check for that agent returns deny at the policy layer — regardless of what the agent’s prompt says. It’s not a “please stop” instruction the model can ignore, argue with, or get talked out of by a crafted input. It’s a flag the model never sees, checked at a layer it doesn’t get a vote on.
“Add a system message telling the agent to stop” is the instinctive first answer, and it’s the wrong layer. A system prompt is an instruction the model interprets alongside every other instruction competing for its attention — including a successful prompt injection, a stuck agentic loop that’s stopped reading new instructions, or a model that simply deprioritizes an instruction buried earlier in context. None of those failure modes are hypothetical; they’re the exact scenarios a kill switch exists for. If the mechanism you’re relying on to stop the agent is inside the same reasoning process that’s currently misbehaving, it isn’t a control. It’s a suggestion.
An operator with the guard.killswitch.write permission calls POST /v1/suite/guard/kill/{agent_id} with a reason. That sets is_killed = trueon the agent’s record — nothing more, and nothing the agent’s own process is involved in.
POST /v1/decisions/check evaluates the killed flag before any other branch. Every subsequent request comes back deny with reason_code: "agent_killed", whatever action the agent was trying to take.
A killed agent can’t mint a new portable trust credential. POST /v1/credentials/issue returns a 403 the moment it checks is_killed, before anything else runs.
A Vault ledger entry (agent.killed), a standard audit-log row, and a danger-severity workspace notification are all written at kill time — there’s a record of who, when, and why, independent of the agent.
POST /v1/suite/guard/unkill/{agent_id}clears the flag and restores normal decision-checking and credential issuance. Killing an agent doesn’t touch its trust score history — it’s a separate, audit-logged operator action.
Be precise about the boundary. The kill switch denies at every checkpoint that asks VeriSwarm for permission — a decision check, a credential request, an A2A task handoff to or from the killed agent. It doesn’t reach into the agent’s own runtime and halt execution mid-task, and it doesn’t revoke credentials the agent already holds and could still present to a system that isn’t checking with VeriSwarm first. That’s why it’s one control among six, not a substitute for the others — least-privilege tool permissions and PII tokenization reduce what an agent can do wrong in the window before anyone reaches for the kill switch at all. See the full six-control checklist.
Activating or reversing the kill switch requires a session token carrying guard.killswitch.write — held by super_admin, platform_admin, tenant_admin, and operatorroles. It is deliberately not reachable with the agent’s own API key: an agent that’s been compromised, or one that’s reasoning its way toward a bad action, can’t kill or unkill itself. The control has to come from outside.
An operator-triggered override that immediately blocks a specific agent's ability to act, without depending on the agent's own code path or cooperation. In VeriSwarm, one call — POST /v1/suite/guard/kill/{agent_id} — flips a flag on the agent's record. From that point on, every trust-decision check against that agent (POST /v1/decisions/check) returns deny with reason_code: "agent_killed", and new credential issuance for that agent is refused outright. It's reversible: an unkill call (POST /v1/suite/guard/unkill/{agent_id}) restores normal operation.
No — a system-prompt instruction is a request the model can be talked out of. That's the core distinction. A real kill switch doesn't ask the agent to stop; it changes what happens when the agent tries to act. The check happens at the decision layer, outside the model's own reasoning loop, so a successful prompt injection, a stuck agentic loop, or the model simply ignoring an earlier instruction doesn't matter — the next decision check comes back denied regardless.
Three things, confirmed against the live decision path: every subsequent call to POST /v1/decisions/check for that agent returns deny (decision_preview.py checks agent.is_killed before any other branch); new portable credential issuance for that agent is refused with a 403 (routes/credentials.py); and, where VeriSwarm's A2A protocol and JIT access checks are in play, other agents' attempts to hand tasks to or grant access to the killed agent are blocked too. What it doesn't do is reach into the agent's own process and stop it mid-execution — see the next answer.
No, and this is the honest limit of a decision-layer kill switch. It denies at every subsequent checkpoint that calls VeriSwarm to ask permission — decisions, credential issuance, A2A task handoff. If an agent has already-issued credentials it can use elsewhere, or it operates in a system that doesn't check VeriSwarm before acting, killing it in VeriSwarm doesn't reach that path. The kill switch is a policy-layer control for agents that check decisions before they act — which is exactly why control #2 on the security checklist (least-privilege tool permissions) and control #4 (injection scanning) matter independently, not as a backup for the kill switch, but as controls that reduce what an agent can do wrong before you'd need to reach for it.
No — activating or reversing it requires a session token with the guard.killswitch.write permission, held by full-access roles (super_admin, platform_admin, tenant_admin, operator). It's not exposed to the agent's own API key, by design: an agent — or something that's compromised it — can't kill itself to cover its tracks, and can't unkill itself either.
The kill switch is part of VeriSwarm Guard, a Max-plan capability. Every activation and reversal writes an immutable Vault ledger entry (agent.killed / agent.unkilled) when Vault is enabled, plus a standard audit-log entry and a danger-severity notification to the workspace — so there's a record of who killed the agent, when, and why, independent of anything the agent itself reports.
The kill switch is a Max-plan Guard capability. Gate’s free tier gives you the decision layer and event visibility it plugs into.