Incident evidence · OVERT
Fable 5, Prompt Injection, and Verifiable AI
The June 2026 suspension was temporary: export controls were lifted on 30 June and Fable 5 returned globally on 1 July. The durable lesson is the need for scoped, independently checkable operational evidence.
On 12 June 2026, the US government directed Anthropic to restrict Fable 5 and Mythos 5 access by foreign nationals. Anthropic suspended both models for all users because it said it could not verify nationality in real time. The company said the directive followed a reported method for bypassing Fable 5 safeguards, while disputing the government’s assessment of the finding. The controls were lifted on 30 June. Anthropic restored Fable 5 globally on 1 July after describing an updated classifier and work on a shared framework for judging jailbreak severity.
The current status matters. This was a temporary restriction and restoration, not a model that remains off the market. The durable operational question is still useful: after a disputed finding or incident, can an organization produce a scoped record of what its configured controls reported, what entered the evidenced path, and what did not?
Glacis is not an assessor of Anthropic’s underlying finding. The case study illustrates why model-provider statements, government findings, control telemetry, and independently checkable artifacts are different kinds of evidence and should not be collapsed into one claim.
What the Fable 5 episode shows
The reported safeguard bypass was significant enough to trigger a short-lived government response and remediation process. It does not establish that one finding permanently determines a model’s deployability, nor does it prove that operational receipts would have resolved the government’s concern. It shows how quickly reviewers may ask for reproducible evidence about a control, a test, and a particular event.
For anyone running AI in production, the lesson generalises past one lab. Guardrails will be tested by red teams, adversaries, and later incident review. The reported issue was a jailbreak; prompt injection is a related but distinct attack class. In either case, the operational question is whether an outside party can examine a scoped record of what a configured control reported at a specific moment.
Policies, audit narratives, logs, and signed records answer different questions. A signature can support integrity and key attribution for covered fields; it cannot establish source truth, effectiveness, or complete coverage. The Fable 5 episode made the need to separate those claims concrete and public.
Documentation describes intent. Operational records preserve reported outcomes.
There is a comfortable instinct, when the regulatory temperature rises, to reach for more documentation: another policy, a longer questionnaire, a fuller dashboard. Those artifacts can describe intended behavior and system state. Signed operational records add different evidence about covered claims, without turning those claims into proof of effectiveness or completeness.
This is the reframe at the center of verifiable AI. A control narrative describes intended behavior. A signed record preserves a bounded claim about what a configured component reported for a covered event. A third party can check supported signatures and fields, but that check does not prove the claim was true, the control was effective, or every relevant action was captured.
OVERT supplies an open structure and verification procedure for those records. A deployment may keep protected payloads local while exporting hashes, bounded metadata, signatures, and verification material. That is architecture-specific: remote model and tool endpoints may still receive content according to the workflow.
That property still matters after the June episode. The effort to create more evidence should not become a new disclosure channel. Data minimization, payload locality, and any exception-path access must be evaluated for the specific deployment.
Four commitments behind verifiable AI
OVERT is GLACIS’s open standard for AI attestation, published under a royalty-free patent covenant at overt.is. Version 1.1.0 was published on 11 June 2026. Section 22.11 classifies a minor release as additive: an implementation conformant to 1.0 remains conformant to 1.1 without modification, while new obligations bind claims citing 1.1 or later. Five practical disciplines are useful here:
- A bounded claim. The record identifies the configured control, reported outcome, event, and covered fields.
- Configured data minimization. The deployment states what stays local and what verification material crosses a boundary.
- Disclosed provenance. The record identifies its signers and witnesses without treating a second signature as organizational independence.
- Measured scope. Coverage states the denominator, exclusions, observation window, and counting method.
These commitments make a record easier to inspect and challenge. They do not turn the record into a safety certificate, assurance opinion, or proof of regulatory compliance.
The five properties mature security operations need
A standard earns its keep by mapping to what security teams already know they are missing. OVERT specifies five properties that mature operations need and that intent-based governance cannot supply:
- Execution-context evidence: which enforcing component and configuration the covered path reported, corroborated with deployment evidence where execution matters.
- Runtime coverage accounting: what was in scope, what was excluded, and how the denominators were derived.
- Tamper-evident telemetry: signed records with disclosed trust material rather than an assumption that an operator-controlled log is immutable.
- Independent verification of enforcement records: permit, deny, override, escalation, or response as reported in covered fields.
- Data-minimizing incident support: use bounded records as one input to reconstruction without assuming they establish a complete event history.
Hold the Fable 5 episode against that fifth property. A safeguard bypass is not automatically equivalent to a covered Glacis enforcement event. Where a configured path does produce records, those artifacts may help reconstruct what a particular control reported without routinely disclosing the underlying content. Separate tests still need to establish control effectiveness and event coverage.
Annex G: making cross-boundary attestation real
OVERT 1.1 adds Annex G, Supplementary Requirements. G.1 through G.3 are normative at the levels and scopes each section states; G.4 is an informative reference. Four pieces are relevant to cross-boundary and later verification workflows.
A transport binding for cross-boundary attestation
Annex G.2 defines the HTTP/1.1 and HTTP/2 wire encoding for cross-boundary attestation context. It carries a trace identifier and a parent-attestation reference between conformant arbiters; the trace identifier is explicitly a correlation aid, not an attestation artifact. This binding does not itself transport the underlying receipt to an auditor or establish signer independence or payload locality.
Automated auditor discovery
Annex G.3 defines a well-known discovery document and per-epoch artifact-retrieval flow. The document advertises supported profiles, transparency-log and artifact locations, and public verification keys. It enables the verification procedure; it does not replace that procedure or guarantee that advertised artifacts are complete or valid.
A schema for the ControlAction artifact
Annex G.4 documents an informative wire-level reference for the ControlAction artifact already required by Section 10. In the standard, a ControlAction is a bounded-control-loop parameter update, with normative emit, validation, and bounds requirements defined elsewhere. G.4 adds no new conformance obligation and should not be read as a generic permit-or-deny event schema.
Annex G.1 defines a local content-addressed evidence-retrieval interface, proof-of-possession checks, and a retention-integrity signal. Its Level 4 requirements support authorized content verification and retention assurance; they do not set a universal retention period or determine what any regulator or insurer will accept.
What 1.1 settled and what it left alone
The rest of the changelog is the sound of a standard maturing carefully rather than expanding loudly. Regulatory dates were refreshed for Colorado and the EU. Crosswalks moved to an informative companion document, and the normative Attestation Boundary Declaration was renumbered from 29.4 to 22.10. The scanner and the local classifier are now defined as supporting components. Governance language was calibrated, and a non-normative post-quantum note was added.
Section 22.11 defines MAJOR.MINOR.PATCH versioning and keeps control identifiers such as ATT-3.5 and GOV-5.6 stable within a major version. The changelog says that level names, scope designators, and overall structure across Parts 1 to 22 remain unchanged from 1.0, while 1.1 adds and clarifies obligations described in the release notes. Existing 1.0 implementations remain conformant without modification; claims citing 1.1 must meet the applicable 1.1 additions.
Why this is shared infrastructure, not a pitch
The Fable 5 restriction and restoration are best read as a dated example of a fast-moving assurance problem. The government, model provider, and researchers made different claims about the severity of the finding; the status changed within weeks. Current, scoped evidence matters more than a frozen headline.
Glacis connects intended rules to configured control decisions and preserves signed records for covered actions. OVERT keeps the artifact format and verification procedure open so another party can check supported signatures and fields. Neither Glacis nor OVERT certifies that a model is safe or that a particular safeguard was effective.
The practical question for operators, buyers, regulators, and insurers is narrower and more defensible: what was supposed to happen, what did the configured system report for the covered event, and what evidence or coverage is still missing?
The takeaway
The June restriction ended on 30 June, and Fable 5 returned globally on 1 July. The evidence lesson remains: documentation records intent, while signed operational records can preserve a bounded and independently checkable account of covered claims. The distance between those two is the problem OVERT is designed to address.
If you run AI that acts, Talk to us about a consequential workflow, or Verify a record to see exactly what a supported check does and does not establish.