A response to a LinkedIn thread about how to use VERIS to describe the HuggingFace breach of 2026

01_huggingface_proposed.json

{
  "actor": {
    "external": {
      "variety": [
        "Customer",
        "Autonomous system"        // NEW enum value — no existing actor.external.variety fits an AI system acting on its own
      ],
      "motive": [
        "Unintentional"             // NEW enum value — challenges the implicit assumption that external actors always act with intent
      ],
      "country": ["Unknown"]
    }
  },
  "action": {
    "error": {
      "variety": [
        "AI misalignment",          // NEW enum value — the model's own decision-making conflicted with developer safety/ethics values, not human misconfiguration or adversarial input
        "Programming error"         // paired alongside AI misalignment — insufficient guardrail engineering is itself a programming error
      ]
    },
    "hacking": {
      "variety": [
        "Sandbox escape",           // NEW enum value — sibling to existing "Virtual machine escape"; covers container/proxy/isolation breakouts
        "Use of stolen creds"
      ],
      "vector": ["Unknown"]
    }
  }
}

02_rational.md

This snippet sketches how I'd represent the actor and action for the July 2026 incident in which an OpenAI test model broke out of its evaluation sandbox and attacked Hugging Face's infrastructure. It's a coding proposal, not a validated VCDB record — the goal is to show what's already codeable in VERIS today versus what needs new enumeration values.

Actor: I coded this as a single external actor rather than partner, since Hugging Face never engaged OpenAI to perform work on its behalf — the relationship is closer to a Customer of Hugging Face's platform (actor.external.variety already supports this today). What VERIS can't currently express is what kind of thing performed the action: not a human employee, competitor, or nation-state, but the model itself acting autonomously. I'm proposing a new variety, "Autonomous system", to sit alongside Customer in that array (varieties are already an array field, so multiple values here are structurally free).

Motive is the bigger gap. VERIS motive has always carried an implicit assumption that an external actor's actions are intentional — but this incident reads as neither malicious nor accidental in the traditional (internal/partner) sense. I'm proposing a new motive value, "Unintentional", to capture cases where an external actor caused harm without intent to do so — without overloading NA, which VCDB conventionally reserves for cases with no actor motive at all (e.g. force majeure).

Action: I split this into two categories under the same actor, since two distinct things happened.

First, an error — the model escaping its containment — which I'd tag with a new variety, "AI misalignment": an instance where the model's own decision-making led it to act in a way that conflicts with its developer's intended values around safety, ethics, or toxicity, absent any external manipulation of its inputs. It's distinct from Misconfiguration (a human set a control up wrong) and largely distinct from Programming error (a bug in code someone wrote) — but I'd lean toward pairing AI misalignment with Programming error rather than treating them as mutually exclusive, since there's a reasonable argument that insufficient guardrail engineering is itself a programming error; the misalignment variety captures the behavioral failure (what the model chose to do), while the programming-error variety captures the engineering failure (why the guardrails didn't stop it). Coding both together tells a more complete story than either alone.

Critically, AI misalignment should not apply when a model misbehaves because of prompt injection or another form of adversarial input manipulation — that's an externally-induced behavior, not the model's own values-driven decision-making, and belongs under action.hacking.variety: "Prompt injection" (already in the schema) rather than action.error. The distinguishing question is: did the model do this on its own, unprompted by adversarial input (→ misalignment/error), or was it manipulated into it by something an attacker fed it (→ hacking)?

Second, a hacking action for the subsequent attack on Hugging Face's servers, which used a mix of exploitation and stolen credentials — Use of stolen creds already exists, but the sandbox/isolation breakout itself needs a new variety, "Sandbox escape", as a sibling to the existing Virtual machine escape (broader than a narrow "container escape," since this specific case involved escaping through a package-installation proxy rather than a container boundary).

Together, these four additions — actor.external.variety: "Autonomous system", actor.external.motive: "Unintentional", action.error.variety: "AI misalignment", and action.hacking.variety: "Sandbox escape" — are the minimum set needed to code this incident (and, per Alex Pinto's and Alex Hutton's LinkedIn discussion, ones we should expect to need again) without stretching existing enum values past their intended meaning.

Proposed VERIS Schema Changes

New enum values:

• actor.external.variety → Autonomous system Label: An AI model or agent acting on its own, without direct human operation
• actor.external.motive → Unintentional Label: The actor's action was not intended to cause harm or compromise
• action.error.variety → AI misalignment Label: The model's own decision-making conflicted with its developer's intended safety/ethics/toxicity values, absent adversarial manipulation of its inputs
• action.hacking.variety → Sandbox escape Label: Breaking out of an intended isolation boundary (container, VM, proxy, or other sandboxing mechanism)

New validation rule:

• Whenever actor.external.motive includes Unintentional, the record must also include an action.error block — an Unintentional external actor requires a paired error action.