Safe release after containment

Use this runbook to lift an incident's emergency denies and restore access deliberately. Release is not undo: it lifts the denies the incident published and nothing else. Suspended agents, revoked grants and revoked credentials each need their own recorded decision.

Before you release

1. Console: Incident detail (/control/orgs/:oid/incidents/:iid). Confirm:

   • the cause is understood and fixed (for example the compromised key is revoked and replaced, see Lost or compromised keys);
   • dispatched_work[] is resolved: every action dispatched before the incident has an outcome_state and, ideally, confirmed: true;
   • nothing in in_flight_actions[] should run once denies lift. Pending and approved actions become resumable again after release unless their deadlines have passed; cancel any you do not want (the agent can call POST /v1/actions/:id/cancel) or keep the agent suspended.

2. Export the incident bundle before release so the contained state is on record:

   axiom_get /v1/incidents/inc_01…/bundle > inc_01…-contained.json

1. Release the incident

Console: Incident detail → Release, with a reason. API (requires incident.respond):

axiom_post /v1/incidents/inc_01…/release '{"reason":"Key rotated, refunds reconciled with finance; INC-2291 closed"}'

• reason is required (at least three characters) and is recorded with released_by and released_at.
• Only open or contained incidents can be released; a second release returns 409 invalid_state.
• Every emergency deny the incident published is lifted (lifted_at, lifted_by, lift_reason). Gateways pick up the change in their next bundle.
• The response includes agents_still_suspended[]: agents the incident suspended that are still suspended. They are not reactivated automatically.

2. Reactivate agents one by one

For each agent in agents_still_suspended[], decide separately. Console: Agent detail → Reactivate agent, with a reason. API (requires agent.write on the agent's tenant):

axiom_post /v1/agents/agt_01…/status '{"status":"active","reason":"Released after INC-2291; new key bound"}'

The agent can request tokens again under its existing grants. A retired agent cannot be reactivated.

3. Restore revoked grants and credentials, if needed

Revocation is permanent. If the incident used revoke_grants: true, a tenant admin issues new grants (Console: Access and delegation, /app/tenants/:tid/access; see Grants and approval thresholds). Delegated child grants are not restored either; the parent agent must delegate again. Revoked credentials are replaced by binding a new key.

4. Verify

• Incident status is released; local_block.active is false.
• GET /v1/orgs/:oid/fleet: every gateway is fresh again with the new policy version acknowledged.
• The SIEM received incident.released and, per agent, agent.reactivated.
• A test action by a reactivated agent is allowed (or pending) as expected; use the policy simulator (POST /v1/projects/:pid/simulate) to check before real traffic.