Org-Wide Emergency Halt
Asqav's org-wide emergency halt is a fail-closed kill-switch for an entire organization. When an organization activates the halt, EVERY new signature is refused with HTTP 403 org_emergency_halt until an admin lifts it. The refusal covers both signing and countersigning, so no new signed receipt can be produced under the org while the halt is in effect.
What is the emergency halt?
The emergency halt is an organization-level control that stops the production of new signed receipts. It is fail-closed by design: once raised, the org's signing surface refuses new work rather than letting it through. While the halt is active:
- A
signrequest is refused with HTTP403and the error codeorg_emergency_halt. - A
countersignrequest is refused with the same403 org_emergency_halt. - The refusal applies to every agent under the organization, not to a single agent.
The halt is raised and lifted through two endpoints:
POST /api/v1/orgs/{org_id}/emergency-haltactivates it.POST /api/v1/orgs/{org_id}/emergency-halt/deactivatelifts it.
Both endpoints are restricted to organization admins and owners under a user session. An agent API key cannot trigger a halt: the kill-switch belongs to the people who run the organization, not to the agents whose signatures it gates.
Why an org-wide kill-switch?
A per-agent control answers "stop this one agent". It does not answer "stop everything, now, across the whole organization". When an incident is in motion - a compromised credential, a misbehaving model, a policy that turned out wrong - an operator needs one switch that closes the whole signing surface at once, without enumerating agents one by one.
An org-wide kill-switch is a control regulators expect. Incident-response and operational-resilience regimes ask an organization to demonstrate that it can halt automated activity under its control on demand and show who authorized the halt. The emergency halt is that demonstrable control on the signed-receipt surface: a single org-level action that fails closed and leaves a record of who raised it and why.
How does it compose with per-agent kill-switches?
Asqav already carries per-agent kill-switches - revoke, suspend, and quarantine - that act on a single agent. The emergency halt is the org-wide layer above that per-agent layer. The two compose:
- The per-agent kill-switches scope to one agent: a revoked, suspended, or quarantined agent cannot sign, while the rest of the organization keeps working.
- The org-wide emergency halt scopes to the whole organization: every agent under the org is refused, regardless of each agent's individual state.
An operator reaches for the per-agent control to isolate one actor and for the org-wide halt to close the entire surface. A halt does not change any agent's individual status. It sits above them and refuses new signatures org-wide until it is lifted.
What does the halt record?
The halt is an auditable action, not a silent flag. When it is raised, Asqav records:
- WHO raised the halt (the admin or owner who called the activate endpoint).
- WHEN it was raised.
- An optional reason, supplied by the caller.
Every blocked attempt is logged while the halt is active, so an auditor can see not only that the organization closed its signing surface but also what was turned away during the window. Lifting the halt is recorded the same way.
Asqav is the record layer, not an inline proxy
The emergency halt stops the production of new signed receipts org-wide. It is a control on Asqav's record layer: it refuses to mint new signed evidence while it is active. It is not an inline proxy sitting in front of an organization's tool calls, and it does not intercept or block the underlying actions an agent might take through other systems.
The distinction matters for how an operator reasons about the halt. Raising it guarantees that no new signed receipt is produced under the organization. It does not, on its own, reach into infrastructure Asqav does not mediate. Operators pair the halt with their own per-agent controls and upstream gating to close the action surface. The halt closes the receipt surface.
How do I raise and lift the halt?
Raise the halt
curl -X POST https://api.asqav.com/api/v1/orgs/org_123/emergency-halt \
-H "Authorization: Bearer $ASQAV_SESSION_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"reason": "credential compromise under investigation"
}'
The reason field is optional. The caller must be an admin or owner of the organization under a user session. An agent API key is refused.
What a blocked signature looks like
While the halt is active, any sign or countersign request under the organization is refused:
{
"error": "org_emergency_halt",
"status": 403
}
The HTTP status is 403 and the error code is org_emergency_halt. The same refusal applies to both signing and countersigning.
Lift the halt
curl -X POST https://api.asqav.com/api/v1/orgs/org_123/emergency-halt/deactivate \
-H "Authorization: Bearer $ASQAV_SESSION_TOKEN"
Once lifted, signing and countersigning resume for the organization's agents according to each agent's individual state.
How does an auditor use the halt record?
The halt leaves a record an auditor can read end to end. To review an emergency-halt event, the auditor:
- Reads WHO raised the halt and WHEN, from the activation record.
- Reads the optional reason supplied by the admin or owner.
- Reviews the logged blocked attempts to see what was turned away while the halt was active.
- Confirms WHO lifted the halt and WHEN, from the deactivation record.
Each step is independently checkable. The halt is org-wide and fail-closed, so an auditor reading the record can confirm that the organization closed its entire signing surface for the recorded window, not just one agent.