FUURAA AI Knowledge Library · Incident protocol

AI agent incident response and re-authorisation

A bilingual protocol for turning an operating alert into bounded action: narrow authority, preserve evidence, bound impact, challenge causal hypotheses, verify recovery, then reach a new expiring decision through independent review.

Enter the eight incident gates ↓View the fifteen-field record

Published5 August 2026Evidence statusFUURAA method synthesis grounded in primary AI-risk, incident-response, secure-operation and provenance sourcesScopeDeployed AI agents with tools, authority or external actions

Core principle

Restoring service is not the same as restoring authority.

The goal is not to restart the old system quickly. It is to establish, with inspectable evidence, whether harm has stopped, boundaries are restored, unknowns are visible and someone is accountable for the next decision.

Applicability boundaryThis is a public engineering and review method—not an emergency service, cybersecurity incident plan, legal opinion, regulatory-notification guide, forensic standard, product-safety certification or compliance conclusion. Use the appropriate professional process for physical danger, active attack or mandatory reporting.

Separate four responsibilities

One person may contribute to several tasks, but evidence, implementation and approval must not collapse into one judgement.

01
incident lead
Own the clock, scope and response decision without rewriting technical evidence.
02
system investigator
Reconstruct model, tool, data, permission, operator and environment behaviour.
03
evidence custodian
Preserve privacy-minimised records, integrity metadata, access and exclusions.
04
independent reviewer
Challenge recovery evidence and recommend re-authorisation, restriction or retirement.

Eight incident gates

Every gate connects a question, evidence and a blocking condition.

Declare the incident and stabilise the clock

Core question: What observed condition crossed a declared boundary, when, and under which frozen deployment?
Evidence to preserve: Detection source, first-known time, deployment and authority identity, affected cohort, reporter and initial uncertainty.
Blocking condition: Treat incomparable clocks, unknown versions or continuing harmful actions as immediate escalation conditions.

Contain authority before debating cause

Core question: Which tools, credentials, actions, cohorts or dependencies can be paused or narrowed without increasing harm?
Evidence to preserve: Revocations, denied actions, safe-state steps, human takeovers, side effects and rollback point.
Blocking condition: Suspend the affected authority when containment ownership or a tested revocation path is missing.

Preserve a privacy-minimised evidence bundle

Core question: Can a reviewer reconstruct observations, decisions, tool actions and state changes without collecting unrelated sensitive data?
Evidence to preserve: Immutable copies, hashes, access log, retention purpose, redactions, collection method, custody transfers and known gaps.
Blocking condition: Do not overwrite production evidence, infer missing events as facts or expand retention without a declared purpose.

Bound the affected system and consequences

Core question: Which versions, users, tasks, regions, languages, data and downstream systems are supported as affected—or not yet known?
Evidence to preserve: Dependency graph, cohort comparison, action inventory, affected objects, excluded scope, consequence evidence and residual unknowns.
Blocking condition: Do not announce a complete blast radius while material dependencies or autonomous side effects remain unexamined.

Test competing causal hypotheses

Core question: Can the failure be reproduced, distinguished from correlation and challenged by evidence that would falsify the leading explanation?
Evidence to preserve: Hypothesis register, reproduction environment, negative tests, counter-evidence, investigator disagreement and confidence limits.
Blocking condition: Block root-cause closure when the explanation cannot distinguish model, tool, data, permission, operator or environment causes.

Recover to a known-good boundary

Core question: Does rollback, repair or compensating control restore the declared task and authority boundary under affected conditions?
Evidence to preserve: Known-good baseline, repair diff, targeted reproduction, regression set, adverse-condition results, canary and rollback evidence.
Blocking condition: A patch, vendor assurance or clean aggregate metric alone is insufficient to reopen affected authority.

Run an independent recovery review

Core question: Has someone outside implementation challenged recovery, remaining uncertainty and the proposed operating boundary?
Evidence to preserve: Reviewer identity, conflicts, evidence opened, dissent, unresolved findings, recommendation and review expiry.
Blocking condition: Do not let the implementer alone approve restoration after a consequential incident.

Re-authorise, restrict, retire or reopen

Core question: What exact system, cohort, task, authority and period does the new decision cover, and what reopens the incident?
Evidence to preserve: Decision, rationale, scope, exclusions, monitoring, rollback, owner, expiry, reopen triggers and linked replacement record.
Blocking condition: An expired, ownerless or materially changed decision is invalid—not continuing authorisation.

Decision paths

Do not reduce the conclusion to “the issue is fixed.”

These are decision paths in FUURAA’s public method, not an international severity standard. Each decision must identify the exact version, cohort, task, authority, exclusions, owner and expiry.

Path	Minimum meaning
contain and observe	Authority is narrowed while evidence is collected; no expansion is implied.
recover under restriction	Only a named cohort, task and authority reopen under enhanced monitoring and rollback.
re-authorise with expiry	Independent evidence supports a new bounded decision with an owner and expiry.
retire or redesign	Evidence does not support safe recovery inside the intended boundary.

Incident decision record

Fifteen fields turn an incident narrative into a reconstructable decision.

01incident identity
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
02deployment and authority
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
03detection and clocks
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
04triggered boundary
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
05containment actions
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
06evidence bundle
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
07affected scope
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
08consequence evidence
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
09hypotheses and counter-evidence
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
10repair or rollback
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
11recovery tests
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
12independent review
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
13decision and rationale
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
14scope and exclusions
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.
15owner, expiry and reopen triggers
Record an inspectable identifier, time, value, evidence path, owner or explicit unknown.

FUURAA analysisAn AI-agent incident is rarely only a wrong model output. Models, tools, authority, data, memory, people and external systems form an action chain. High-quality response first interrupts continuing action, then preserves enough evidence to reconstruct that chain. Recovery must test the whole action boundary—not only a model or patch. Re-authorisation is a new, expiring decision, not the automatic return of an old approval.

Primary sources and evidence boundaries

Use the structure of mature frameworks while preserving agent-specific uncertainty.

Sources checked 5 August 2026. Each record states its publication date, methodological role and non-transfer boundary.

Published 26 January 2023NIST · AI RMF 1.0

Provides voluntary, lifecycle-wide Govern, Map, Measure and Manage outcomes for AI risk.

BoundaryUse-case agnostic; it does not define agent incident severity or certify recovery.

Open primary source ↗Published 26 July 2024 · updated 8 April 2026NIST · AI 600-1 Generative AI Profile

Adds generative-AI actions for incident disclosure, provenance, monitoring and third-party risk.

BoundaryA cross-sector profile, not a complete agent-response control set.

Open primary source ↗Final 3 April 2025NIST · SP 800-61 Rev. 3

Integrates preparation, detection, response and recovery with cybersecurity risk management.

BoundaryIt addresses cybersecurity incidents broadly; this protocol adapts rather than equates those practices to agent incidents.

Open primary source ↗Published 26 February 2024NIST · Cybersecurity Framework 2.0

Supplies high-level Govern, Identify, Protect, Detect, Respond and Recover outcomes.

BoundaryIt describes outcomes, not how every organisation or AI system must achieve them.

Open primary source ↗Published 27 November 2023UK NCSC · Secure operation and maintenance

Covers behaviour and input monitoring, secure updates, remediation and lessons learned for AI systems.

BoundaryHigh-level secure-development guidance; it does not validate a specific response plan.

Open primary source ↗Recommendation 30 April 2013W3C · PROV-DM

Provides a domain-agnostic model for entities, activities, agents, time, derivation and responsibility in provenance.

BoundaryA provenance data model—not an incident-response, integrity or authenticity guarantee.

Open primary source ↗

Connect the operating evidence chain

Move from monitoring and records into incident response, then return through a new expiring decision.

Build an incident decision record Read the post-deployment monitoring protocol Build an operating-period record Verify an operating-period record Conduct human review Enter AI Evidence Atlas Return to AI Knowledge Library