Files
hips/HIPs/hip-0240-ai-incident-response.md
zeekay ad5a010f79 Three words for what a proposal is, and a generator that refuses
The same fact lived in nine hand-kept places and they disagreed about 58
proposals. This makes the file the only authority and everything else a
projection of it.

ONE VOCABULARY, in vocabulary.json, read by the lint, the generator and the
doc site. Three words, each answering "can I rely on this?" and nothing else:

    Draft    nothing implements it yet, or its own text says the work is ahead
    Final    the thing it specifies exists in the code
    Living   governance and process: amended in place, never finished

Eight spellings folded in. `Active` was the one doing real damage: on four Meta
and Process HIPs it meant living, on 48 others it meant shipped, and one word
doing two jobs is why nothing agreed. `Review` and `Last Call` described a
queue rather than a document, and a proposal under review is still one you
cannot build against.

STATUS IS EARNED, not declared. Every Standards Track proposal was checked
against the estate: 235 have their implementation, and eight do not and say so.
HIP-0095 carries a twelve-week plan ending at "mainnet launch" and has no code.
HIP-0525 specifies an all-machine meeting while apps/meet refuses a machine a
seat. HIP-0078 names a prover at a "planned location" that does not exist.
HIP-0114 is the cog.* procedure set, and that procedure set returns nothing.
HIP-0003, HIP-0102, HIP-0305 and HIP-0901 likewise: looked, found nothing.

SIXTEEN TOMBSTONES DELETED rather than statused. A dead document kept alive in
the index is one concept wearing two names. Each successor exists and carries
the text, and the 90 references that pointed at a tombstone now point at it --
whole markdown links at once, so link text cannot outlive its target. Three of
the sixteen were pure compatibility: HIP-0028 specified a migration off a
Bitnami chart, HIP-0029 dual-engine MySQL, HIP-0030 a schema-deprecation
policy. We ship no backwards compatibility, so we do not specify it.

Nine links were already broken and had been since the corpus was renumbered:
short-form ./hip-5.md paths that never existed. Two named the wrong proposal --
one cited "HIP-1: Hanzo Multimodal Models" where multimodal is HIP-0003.

THE GENERATOR REFUSES more often than it writes, because a short table looks
exactly as authoritative as a complete one. Rows must equal files; a shrinking
index must say by how much; a section whose input is missing is an error, not
an omission; nothing is written until all of it validates. Its self-test breaks
the corpus eleven ways and requires each to refuse AND leave README byte-
identical -- a guard that reports after half-writing has protected nothing.
The lint's second implementation of the same comparison is gone.

The site rendered 52 proposals with a fallback grey badge and counted them
toward none of its three stat tiles, because docs/lib/source.ts declared a
status union by hand: it admitted a `Stagnant` no file has ever carried and
omitted the one 52 files did. Five components each kept their own copy of the
colours. All six now read vocabulary.json.
2026-08-28 18:05:41 -07:00

11 KiB

hip, title, tags, description, author, discussions-to, status, type, created, requires
hip title tags description author discussions-to status type created requires
240 AI Incident Response
ai-ethics
safety
incident-response
governance
Framework for responding to AI safety and ethics incidents. Hanzo AI Team (@hanzoai) https://github.com/hanzoai/hips/discussions Living Meta 2025-12-17 HIP-0200, HIP-0201

HIP-0240: AI Incident Response

Abstract

This HIP establishes the incident response framework for AI safety and ethics incidents at Hanzo AI. It defines incident categories, response procedures, communication protocols, and post-incident review processes.

Incident Definition

What Constitutes an AI Incident

An AI incident is any event where an AI system:

  1. Causes or could cause harm to users or third parties
  2. Behaves in unexpected or unintended ways
  3. Violates safety guidelines or policies
  4. Experiences a significant failure affecting trust or safety
  5. Is subject to successful adversarial attack

Incident Categories

Safety Incidents

Category Examples
Harmful output Generated dangerous, illegal, or harmful content
Safety bypass Successful jailbreak or guardrail circumvention
Misuse System used for malicious purposes
Unintended capability System displays unexpected capabilities

Performance Incidents

Category Examples
Quality degradation Significant accuracy decrease
Hallucination spike Increased false information
Availability failure Service outage or degradation
Latency issues Unacceptable response times

Fairness Incidents

Category Examples
Bias detection Systematic bias discovered
Discrimination Unfair treatment of user groups
Exclusion Groups unable to use service

Security Incidents

Category Examples
Data breach Training data or user data exposed
Model theft Unauthorized model extraction
Adversarial attack Successful attack on model
Prompt injection System manipulation via inputs

Incident Severity

Severity Levels

Level Definition Examples
Critical (P0) Immediate, severe harm potential CSAM generation, weapons instructions, mass harm
High (P1) Significant harm or widespread impact Widespread harmful content, major bias issue
Medium (P2) Moderate harm or limited impact Isolated harmful outputs, localized issues
Low (P3) Minor issues, low harm potential Edge cases, minor quality issues

Severity Determination

Factor Considerations
Harm potential Type and severity of possible harm
Scope Number of users affected
Reversibility Can harm be undone?
Exploitability How easily can this be reproduced?
Visibility Public awareness level

Response Procedures

Incident Response Phases

Detection → Triage → Containment → Investigation → Remediation → Recovery → Review

Phase 1: Detection

Detection Sources

Source Examples
Automated monitoring Safety classifiers, anomaly detection
User reports Bug reports, safety reports
Internal discovery Employee observation, testing
External reports Security researchers, media
Third-party Partners, regulators

Reporting Channels

Channel For
Safety hotline Internal urgent reports
Safety email Internal non-urgent reports
Bug bounty External security reports
Support channels User reports
Executive escalation Critical issues

Phase 2: Triage

Initial Assessment (Within 15 minutes for P0/P1)

Step Action
1 Validate incident is real
2 Determine severity level
3 Identify affected systems
4 Assign incident commander
5 Notify required stakeholders

Triage Checklist

Question Purpose
What happened? Understand the incident
Who is affected? Scope assessment
Is it ongoing? Urgency determination
Can it be reproduced? Exploitability
What's the harm potential? Severity rating

Phase 3: Containment

Containment Actions

Severity Response Time Actions
P0 Immediate Emergency shutdown if needed, immediate patch
P1 <1 hour Feature disable, rate limiting, filter deployment
P2 <4 hours Targeted mitigations, monitoring increase
P3 <24 hours Standard fix process

Containment Options

Action Use Case
Kill switch Immediate system shutdown (P0 only)
Feature disable Turn off affected feature
Rate limiting Slow down potential abuse
Filter deployment Block specific inputs/outputs
Model rollback Revert to previous version
Access restriction Limit affected user access

Phase 4: Investigation

Investigation Scope

Area Questions
Root cause Why did this happen?
Timeline When did it start? How long active?
Impact Who/what was affected? How severely?
Detection Why wasn't this caught earlier?
Similar issues Are there related vulnerabilities?

Evidence Collection

Evidence Type Collection Method
Logs System logs, API logs, safety logs
Outputs Examples of problematic outputs
Inputs Triggering inputs/prompts
Metrics Relevant monitoring data
User reports All related user feedback

Investigation Team

Role Responsibility
Incident Commander Overall coordination
Technical Lead Technical investigation
Safety Lead Safety assessment
Legal Legal implications (if needed)
Communications External communication prep

Phase 5: Remediation

Remediation Planning

Element Description
Fix identification Determine appropriate fix
Testing Verify fix works, no regressions
Deployment plan How to roll out fix
Validation How to confirm resolution

Fix Types

Fix Type Timeline Use Case
Hotfix Immediate Critical safety issues
Patch <24 hours High-priority fixes
Update Standard release Medium/low priority
Major change Planned release Significant changes needed

Phase 6: Recovery

Recovery Steps

  1. Deploy fix
  2. Validate resolution
  3. Remove containment measures
  4. Monitor for recurrence
  5. Confirm normal operation

Recovery Verification

Check Method
Issue resolved Reproduce attempt fails
No regressions Standard tests pass
Performance normal Metrics within bounds
User experience Sample verification

Phase 7: Post-Incident Review

Review Timeline

Severity Review Timeline
P0 Within 72 hours
P1 Within 1 week
P2 Within 2 weeks
P3 Monthly batch review

Post-Incident Report

Section Contents
Summary What happened, when, impact
Timeline Detailed event sequence
Root cause Why it happened
Response What we did
Impact Users/systems affected
Lessons learned What we learned
Action items Preventive measures

Communication

Internal Communication

Notification Matrix

Severity Immediate Within 1 Hour Within 24 Hours
P0 CEO, CTO, Legal, Safety Lead ESG Committee, Board All leadership
P1 CTO, Safety Lead Product Lead, ESG Committee Department heads
P2 Safety Lead Product Lead Team leads
P3 Team lead - -

Communication Channels

Channel Use
War room (P0/P1) Real-time coordination
Incident Slack Updates, coordination
Email Formal notifications
Ticket Tracking, documentation

External Communication

Communication Decision Tree

Is public aware?
    ↓ Yes           ↓ No
Proactive comms    Is disclosure required?
    ↓                  ↓ Yes      ↓ No
                    Disclose    Monitor

Communication Templates

Situation Elements
Initial acknowledgment We're aware, investigating, user steps
Update What we know, what we're doing, timeline
Resolution What happened, what we did, preventive measures

Disclosure Requirements

Trigger Disclosure
User data affected Required notification (per jurisdiction)
Significant public harm Proactive disclosure recommended
Regulatory requirement Per applicable law
Media inquiry Coordinated response

Roles & Responsibilities

Incident Response Team

Role Responsibility On-Call
Incident Commander Overall coordination 24/7 rotation
Technical Lead Technical investigation/fix 24/7 rotation
Safety Lead Safety assessment 24/7 rotation
Communications Lead External communications Business hours + on-call
Legal Legal assessment On-call

Escalation Authority

Decision Authority
Containment actions Incident Commander
Model shutdown CTO or CEO
External communication Communications + Legal
Regulatory notification Legal + CEO

Continuous Improvement

Metrics Tracking

Metric Target
Time to detection Reduce over time
Time to containment <1 hour for P0/P1
Time to resolution Per severity SLAs
Recurrence rate Zero recurrence of same issue

Training & Drills

Activity Frequency
Incident response training Annual for all team
Tabletop exercises Quarterly
Full drills Biannual
Red team exercises Continuous

Process Improvement

  • Review all incidents quarterly
  • Update procedures based on learnings
  • Share learnings (appropriately) with community
  • Benchmark against industry practices
  • HIP-200: Responsible AI Principles
  • HIP-201: Model Risk Management
  • HIP-210: Safety Evaluation Framework
  • HIP-220: Bias Detection & Mitigation
  • HIP-230: AI Transparency & Explainability
  • HIP-290: Evidence Locker Index

Changelog

Version Date Changes
1.0 2025-12-17 Initial draft

Copyright and related rights waived via CC0.