Emergency, Security, and Incident Governance

Draft 0.1 — 2 August 2026
Emergency authority is a temporary operational capability. It does not override applicable law, legal-entity authority, due process, provider controls, or constitutional limits.

Objective

ANUKA’s shared identity, consent, reputation, payment, product, and Presence systems create real cross-product risk.

An incident may require action before ordinary governance can finish a review period.

The emergency system must therefore support:

rapid containment;
clear command;
preservation of evidence;
protection of participants and funds;
temporary restrictions;
communication under uncertainty;
recovery;
independent retrospective review;
automatic expiry of extraordinary powers.

The core rule is:

Emergency powers exist to contain a defined incident, not to win an unrelated governance dispute.

Incident classes

Security incident

Examples:

credential theft;
key compromise;
malicious extension release;
unauthorized access;
source-code compromise;
supply-chain attack;
denial of service;
data exfiltration.

Privacy incident

Examples:

unauthorized disclosure;
consent bypass;
accidental publication;
cross-product data leakage;
re-identification;
use beyond declared purpose.

Payment incident

Examples:

payment-provider compromise;
fraudulent payout campaign;
duplicate transfer;
reserve exhaustion;
negative-balance cascade;
sanctions alert;
chargeback attack.

Identity and reputation incident

Examples:

fraudulent credential issuer;
compromised attester;
mass false attestations;
invalid score deployment;
corrupted status registry;
coordinated identity abuse.

AI-agent incident

Examples:

agent exceeds grant;
prompt or tool compromise;
unauthorized data access;
mass harmful action;
model/provider behavior change;
false governance execution.

Governance incident

Examples:

compromised voting or proposal system;
unauthorized role grant;
hidden modification of a ratified document;
captured council acting outside charter;
deliberate destruction of decision records.

Legal or safety incident

Examples:

regulator or court order;
credible threat to a person;
sanctions requirement;
urgent legal preservation duty;
dangerous product behavior.

Severity levels

Incident indicator

Incident severity scale

Severity classifies confirmed impact and the proportional response; it does not replace accountable incident judgment.

SEV-0

Observation

Impact: Suspicious signal, no confirmed material impact.

Response: Record, investigate and increase monitoring.

SEV-1

Limited

Impact: Confirmed limited scope with low material harm.

Response: Apply a scoped control, notification or rollback.

SEV-2

Material

Impact: Multiple users, important data, funds or shared services affected.

Response: Pause affected capability and coordinate recovery.

SEV-3

Critical

Impact: Ongoing or imminent network-wide risk.

Response: Use incident command and time-limited emergency powers.

SEV-0 — Observation

Suspicious signal with no confirmed material impact.

Actions:

record;
investigate;
increase monitoring;
avoid public claims of breach without basis.

SEV-1 — Limited

Confirmed issue affecting a limited scope with low material harm.

Actions may include:

scoped credential revocation;
feature disablement;
participant notification;
local rollback.

SEV-2 — Material

Confirmed incident affecting multiple users, important data, funds, or shared services.

Actions may include:

product or service pause;
payout hold;
key rotation;
public status update;
emergency vendor engagement.

SEV-3 — Critical

Ongoing or imminent risk to network-wide security, substantial funds, sensitive data, or critical identity infrastructure.

Actions may include:

network capability shutdown;
broad credential revocation;
emergency treasury spending;
coordinated legal and provider response;
mandatory incident command.

Severity must be reassessed as evidence changes.

Security Response Charter

ANUKA must publish a charter defining:

response body;
on-call roles;
incident commander appointment;
allowed actions by severity;
financial limits;
data access;
communication authority;
legal escalation;
provider contacts;
decision logging;
maximum duration;
retrospective review;
appeal and correction.

Incident roles

Incident Commander

Coordinates response, assigns work, maintains priorities, and decides within the emergency charter.

The Incident Commander does not automatically become the final investigator, disciplinary decision-maker, or constitutional authority.

Security Lead

Directs technical containment, evidence preservation, remediation, and recovery.

Privacy Lead

Assesses affected data, consent, notification, minimization, and privacy obligations.

Payment Lead

Coordinates payment providers, holds, reserves, refunds, payout restrictions, and reconciliation.

Communications Lead

Publishes accurate, scoped, time-stamped updates.

Legal Liaison

Coordinates counsel, legal preservation, notices, regulators, law enforcement, and contractual duties where relevant.

Records Secretary

Maintains incident timeline, decisions, approvals, evidence references, and later review materials.

One person may hold multiple roles in a small incident, but conflicts and control weaknesses must be recorded.

Emergency capabilities

A charter may allow responders to:

revoke or suspend credentials;
disable compromised APIs, extensions, widgets, agents, or services;
rotate secrets and keys;
block malicious origins or accounts;
pause new assignments;
hold or delay payouts under applicable terms;
disable a shared registry write path;
roll back a release;
preserve logs and evidence;
isolate a resident product from shared services;
require step-up authentication;
suspend a delegated role;
spend from a security reserve within a cap;
publish urgent warnings.

Every action must be:

necessary;
proportionate;
scoped;
logged;
attributed;
reversible when practical;
reviewed.

Prohibited emergency actions

Emergency authority must not be used to:

permanently amend the Constitution;
create a new permanent council;
transfer ownership of core assets without lawful authority;
confiscate participant funds outside applicable law and contracts;
settle unrelated political or product disputes;
suppress good-faith criticism;
create undisclosed permanent surveillance;
alter historical evidence to improve appearances;
impose indefinite restrictions without review;
expand responder authority beyond the incident.

Time limits

Recommended limits:

Action	Initial maximum without renewal
temporary session or token revocation	immediate, status persists while credential is invalid
local feature pause	24 hours
shared-service pause	72 hours
emergency role suspension	72 hours
payout or treasury hold	according to provider/contract, governance review within 72 hours
emergency policy exception	7 days
emergency spending authorization	transaction-specific, retrospective review within 7 days

Renewal requires a reasoned record and the next higher approval level where practical.

Incident lifecycle

Interactive growth flow

Incident response timeline

Containment is time-bounded operational work: each step preserves accountability, evidence and the path back to normal operations.

Legend: select a numbered step to read its description.

Step 1. Maintain roles, contacts, backups, access controls, templates, exercises and emergency resources.

Maintain roles, contacts, backups, access controls, templates, exercises and emergency resources.
Record the signal, preserve evidence, assess credibility, classify severity and appoint command.
Stop ongoing harm, narrow access, isolate systems and protect funds and data.
Remove malicious access, patch, rotate keys and correct affected controls.
Restore only necessary services gradually, verify integrity and monitor recurrence.
Record causes, impact, decisions, corrective actions, owners and due dates.

Prepare

role registry;
contacts;
backups;
access controls;
provider escalation paths;
exercises;
communication templates;
logging;
insurance and counsel contacts;
emergency budgets.

Detect and validate

receive signal;
establish incident ID;
preserve evidence;
assess credibility;
classify severity;
appoint commander;
avoid destructive investigation steps.

Contain

stop ongoing harm;
narrow access;
revoke compromised authority;
isolate affected systems;
protect funds and data;
record decisions.

Eradicate and remediate

remove malicious access;
patch vulnerabilities;
replace keys;
correct policy or configuration;
validate dependencies;
review affected credentials and records.

Recover

restore services gradually;
verify integrity;
monitor for recurrence;
communicate limitations;
reconcile payments and data;
restore only necessary permissions.

Review and learn

timeline;
root and contributing causes;
impact;
decisions;
emergency powers used;
communication quality;
missed signals;
corrective actions;
owners and deadlines;
policy or architecture changes.

NIST SP 800-61 Rev. 3 frames incident response as part of broader cybersecurity risk management rather than a separate last-minute function.

Incident record

Minimum fields:

Record at a glance

Incident record

Field	Example value	Why it matters
INC-2026-0042 · SEV-2 · contained	Reference, severity, and current state.
Started 12:14 UTC · detected 12:26 UTC	Known time markers.
participant:anuka:security-1	Accountable incident lead.
Passport API · Credential status	Bounded technical impact.
Suspend issuer · approved by security-2 · expires 5 Aug	Temporary, reviewable intervention.
Update 14:00 UTC · review 9 Aug	When public and governance updates are due.

Sensitive technical details may be restricted, but public impact and governance use should be reported.

Communications

Incident communications should distinguish:

confirmed facts;
current assessment;
actions taken;
affected scope;
participant actions required;
uncertainty;
next update time;
correction history.

Avoid:

premature blame;
false certainty;
minimizing known harm;
publishing exploitable details during active containment;
disappearing after the first announcement.

Notification authority

The response charter must identify who may notify:

affected users;
resident products;
payment providers;
insurers;
counsel;
regulators;
law enforcement;
the public.

Legal notification decisions require applicable counsel and entity authority.

Evidence preservation

Responders should preserve:

logs;
access records;
commits and artifacts;
configuration;
provider events;
messages;
credentials and status changes;
payment records;
decision approvals;
hashes and timestamps;
chain of custody where relevant.

Evidence collection must respect privacy and privilege.

Payment and treasury incidents

A payment incident may justify temporary holds, but the system must distinguish:

provider hold;
contractual reserve;
fraud review;
sanctions block;
dispute amount;
platform treasury restriction;
contributor payable.

The interface must not falsely suggest ANUKA has legal custody or discretion it does not possess.

Credential and reputation incidents

If an issuer, reviewer, schema, or source becomes unreliable, ANUKA may:

suspend the issuer;
mark credentials as disputed;
revoke or supersede affected credentials;
remove a score from decision use;
require re-verification;
notify relying parties;
preserve historical status.

Revocation must not rewrite the fact that a credential existed.

AI incidents

Emergency response may:

disable tools;
revoke agent grants;
freeze agent-created proposals;
require human confirmation;
block provider or model version;
quarantine outputs;
rotate credentials;
inspect relevant logs.

The principal remains accountable for the agent’s actions within applicable law and agreements.

Resident-product incidents

A resident product may be temporarily disconnected from shared services when it creates material cross-network risk.

The action record must identify:

affected capability;
evidence;
duration;
remediation conditions;
participant communications;
review and appeal route.

Temporary disconnection is not automatic permanent separation.

Retrospective review

A SEV-2 or SEV-3 incident requires a retrospective review.

The review body should include at least one person who did not direct the response when practical.

The report should assess:

whether emergency authority was valid;
proportionality;
conflicts;
missed approvals;
participant harm;
unnecessary data access;
communication accuracy;
financial effects;
corrective action completion;
whether rules need amendment.

Emergency action appeals

An affected participant may challenge:

mistaken scope;
excessive duration;
inaccurate public claim;
improper payout hold;
conflict of interest;
failure to provide review;
permanent consequence imposed under temporary authority.

The appeal may proceed after containment when immediate review would increase risk.

Vulnerability reporting

ANUKA should publish:

security contact;
supported disclosure method;
encryption key where appropriate;
expected acknowledgement time;
scope;
safe testing guidance;
prohibited harmful testing;
remediation and credit policy;
bug bounty status if available.

A vulnerability reporter should not need to publish an exploit publicly to receive attention.

Exercises

The response team should practice:

extension compromise;
Passport issuer compromise;
payment fraud and reserve loss;
leaked admin token;
malicious AI agent;
registry corruption;
resident-product disconnection;
key recovery;
communications failure;
founder or council account compromise.

Exercises should produce corrective actions, not ceremonial checklists.

Minimum implementation baseline

Before launching shared production services, ANUKA should have:

Security Response Charter;
incident severity model;
on-call contacts;
credential and capability revocation;
central incident records;
backups and restore tests;
provider escalation paths;
emergency spending limits;
communication templates;
vulnerability disclosure page;
annual exercise;
retrospective review process.

Sources

Verification record

Sources opened and checked: 2 August 2026
Incident baseline: NIST SP 800-61 Rev. 3, April 2025
Security charter adopted: No
Production readiness review required: Yes