Product · Kill switch
One switch to stop the estate — and prove every step
When something goes wrong you should not be hunting for off-switches. One engage flips your whole AI estate — or a single agent — to a stop that every governed actuation gate consults before it acts. Engaging is deliberately cheap; getting back out takes two people and a written review.
In the product
The emergency-stop console
A genuine screenshot, example data. The live stop posture, the one-click engage (estate-wide or a single agent), the dual-control re-enable, the forced post-review and a downloadable, tamper-evident evidence pack — every action recorded to the ledger.
How it behaves
Cheap to stop, deliberate to undo
An emergency stop has to be instant and unconditional; coming back has to be careful. The switch is built around that asymmetry.
One engage, every governed surface
Engaging stops the estate — or one agent — across the governed actuation surfaces (hooks, MCP, orchestration, voice, models, deploy and eventing) and revokes in-scope pending approvals. There is no approval gate on engaging: in an incident, stopping is free.
The single source of truth
A stop is a row every actuation gate consults live before it acts. While it is active, in-scope governed actions are denied — deny-closed, not best-effort.
Dual-control recovery
Re-enabling is what the controls guard: two distinct people, then a forced post-review. You cannot quietly switch the estate back on alone.
Tamper-evident evidence
Who engaged, when, the scope, the reason, the revoked approvals and the full re-enable and review lifecycle — anchored to the append-only ledger and exportable as an incident evidence pack.
What’s real
A built surface — and honest about its reach
The kill switch is a real, audited governance surface — its gate decisions, floors and sentinels live in the engine; the console is a thin client. Two honest notes on what “stop” means:
- It is a deny gate, not a process killer. Engaging flips a stop that the governed actuation gates consult and revokes in-scope pending approvals, denying governed actions deny-closed. It does not reach outside the surfaces Olivares governs to terminate arbitrary processes.
- Its reach follows your wiring: where an actuation surface is connected and governed, the stop applies there — the same deny-closed posture that governs actuation governs the stop.
- Engaging is intentionally unguarded; recovery is not. Re-enable requires dual control and a forced post-review, with every step in the evidence pack.
Kill switch — questions
Does engaging kill running agent processes?
No — it is a deny gate, not a process killer. Engaging flips a stop that every governed actuation gate consults before it acts, and revokes in-scope pending approvals, so governed actions are denied deny-closed while the stop is active. It governs the actuation surfaces Olivares controls; it does not reach out to terminate arbitrary processes on your hosts.
Why is there no approval to engage?
Because in an incident, stopping must be instant and frictionless. The control is on the way back: re-enabling requires two distinct people and a forced post-review. Stopping is cheap by design; undoing a stop is deliberate.
Can I stop just one agent?
Yes. The scope is estate-wide or a single agent. A single-agent stop reads as a warning; an estate-wide stop is loud — both are persisted, audited and recoverable only under dual control.
What evidence do I get?
Every stop records who engaged it, when, the scope, the mandatory reason, the approvals it revoked and the full re-enable and post-review lifecycle — anchored to the append-only, hash-chained ledger and exportable as a tamper-evident incident evidence pack.
Put a real stop button on your estate
Deploy Olivares on your own infrastructure and give your operators one audited, dual-controlled way to stop — and to prove they stopped — when it matters.