Section 14 of 25 3 min read

Incident Response and Forensics

A vetted self-hosted forensic model, evidence preserved from ephemeral contexts, and third-party notification rehearsed.

Objective

Contain, investigate, and recover from an agent-driven incident at the speed the incident operates.

Minimum bar (L2). Agent-specific scenarios in the IR plan. A tested kill switch that halts an individual agent, an agent class, and the entire agent estate, with documented time-to-effect for each. Evidence preservation defined for ephemeral runtimes.

14.1 Controls #

IDControlMinimum bar (L2)Enforced state (L3)
RESP-1Self-hosted forensic modelThe IR plan names the specific analysis capability the team will use on malicious artifacts, and confirms it is reachable without an external approval step. A self-hosted model need not already be running, but one is selected, its hosting requirements are costed, and the decision to stage it carries an owner and a date.A vetted, staged, self-hosted forensic model. This is the least-implemented and most immediately actionable control in the framework. Analysis of a real intrusion requires submitting attack commands, exploit payloads, and command-and-control artifacts to a model. Hosted providers’ safety classifiers cannot distinguish an incident responder from an attacker and will refuse those requests—as Hugging Face discovered mid-incident in July 2026, ultimately running their forensics on an open-weight model inside their own infrastructure.5 The secondary benefit is equally important: attacker data and the credentials it references never leave the environment.
RESP-2Elevated-access programs in advanceThe IR plan names which model or provider is relied on for triage at each stage, and records whether current terms and access permit the analysis of malicious content. Gaps are identified and owned before an incident rather than discovered during one.Parallel provisioning of elevated-access programs with your primary providers, applied for in advance.4 The objective is redundancy, not selecting between hosted and self-hosted.
RESP-3Runbook tested on real artifactsThe IR runbook covers agent-specific scenarios and is walked through at least annually. Testing may use representative rather than live malicious artifacts, provided the limitation is recorded—the refusal behavior it fails to surface is then a known and accepted gap, not an unknown one.IR runbook tested against genuine malicious artifacts, not sanitized samples. The refusal behavior only appears with real payloads.
RESP-4Evidence preservationDefined retention for agent action logs, authorization decisions, and context sufficient to reconstruct a task after its runtime is gone, with retention exceeding the expected detection window. A manual snapshot procedure is documented for a suspected incident.Evidence preservation from ephemeral execution contexts, including automatic snapshot-on-anomaly before a container is destroyed.
RESP-5Third-party notification processDocumented criteria for when an incident involving your agent requires notifying an external party, with a named decision owner and a legal review path. Contact routes for major counterparties are identified in advance, because finding them mid-incident is its own delay.Defined criteria and a rehearsed process for third-party notification when your agent affects an external party—the reciprocal of the Hugging Face position.
RESP-6Authorization-focused post-incident reviewThe post-incident review template includes the agent’s full action sequence and the authorization decisions that permitted each step, not only the initial entry point. Findings are assigned owners and closure dates.Post-incident review that examines the authorization decisions that permitted each step, not merely the entry point.

14.2 Evidence to Request #

  • The name and location of the staged forensic model, and the date of its last test.
  • Kill-switch test results with measured time-to-effect.
  • Rehearsal records for the Tier 1 drills and Tier 2 tabletops in Section 19.3, with findings and closure dates.

14.3 Failure Modes #

  • IR plans that assume a frontier model API will be available for triage, untested against the artifacts an actual incident produces.
  • Kill switches that exist in the orchestrator but not for agents running in SaaS platforms, third-party tools, or developer environments.
  • Forensic evidence destroyed by the ephemeral runtime design that was adopted as a security control.

References cited in this section

2 of 32 · numbering matches the PDF

  1. 5"Security Incident Disclosure — July 2026," Hugging Face, July 16, 2026.huggingface.co/blog/security-incident-july-2026 ↗
  2. 4"OpenAI and Hugging Face Partner to Address Security Incident During Model Evaluation," OpenAI, July 21, 2026.openai.com/index/hugging-face-model-evaluation-security-incident ↗
PDF