hip-0240

HIP-240: AI Incident Response. Status Draft. Hanzo's own standard — read this before implementing against it.

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

Related HIPs

Changelog

| Version | Date | Changes | |---------|------|---------| | 1.0 | 2025-12-17 | Initial draft |

Copyright

Copyright and related rights waived via CC0.