Plugin
Kill switch plugin
RegulusKillSwitchPlugin Identity-backed dual-control kill switch. Two authorised Principals must invoke the switch to collapse an agent's tool surface. Fail-closed afterwards; engagement events feed the audit chain.
What it does #
The kill switch is the agent’s circuit breaker. When engaged, the
agent’s tool surface collapses: every subsequent tool call returns a
structured KILL_SWITCH_ENGAGED decision, and the audit chain
captures the engagement event with both authorising Principals.
Why dual control #
A regulated agent’s kill switch is itself a privileged action — one
that can deny service to real users mid-transaction. Single-actor
authority on the switch is a single point of failure for incident
response. The plugin requires two authorised Principals (both
carrying the tier-authority claim) to engage. Disengagement is also
dual-control.
How to engage #
Two paths, both producing the same audit event:
Programmatic:
killSwitch.engage(
primaryPrincipal,
secondaryPrincipal,
Reason.MODEL_DRIFT,
"Tier-2 model exceeded outcome-monitoring threshold at 22:14Z"
);
CLI:
$ regulus kill-switch engage \
--agent credit-decision \
--primary "$JWT_1" \
--secondary "$JWT_2" \
--reason MODEL_DRIFT \
--message "Tier-2 model exceeded outcome-monitoring threshold at 22:14Z"
Both write to the same KillSwitchStore; both produce the same audit
event in the chain.
Once engaged #
Every tool call fails with a structured decision:
{
"decision": "KILL_SWITCH_ENGAGED",
"engaged_at": "2026-06-01T22:14:03Z",
"engaged_by": ["sub:dipankar", "sub:another-validator"],
"reason": "MODEL_DRIFT"
}
The agent’s read paths remain available — model invocations still work for diagnostic purposes — but no state-changing tool dispatches. This is intentional: an incident-response team needs to query the agent to understand what happened.
Disengagement #
Same dual-control gate, opposite direction. Both engagement and
disengagement events land in the audit chain with the authorising
Principals.
Status today #
The InMemoryKillSwitchStore is the default backend, suitable for
single-instance deployments. Multi-instance / persisted backends are
on the v0.3 roadmap — a JDBC store is in flight. For multi-instance
deployments today, configure a shared external switch via the
KillSwitchStore SPI.