Incident Response

How to Maintain Compliance When AI Models Are Recalled or Suspended Under Export Control Directives

Provider-agnostic incident response playbook for model recall events, with cryptographic evidence procedures and regulatory mapping

Home / Guides / Export Control Model Recall

Audience: Compliance officers, AI engineers, legal teams, and incident responders at organizations operating AI models in regulated environments. This guide is provider-agnostic. The June 12 Anthropic directive is used as a case study, but the procedures apply to any model recall from any provider.

This guide was published within 24 hours of the first government-ordered AI model recall at scale. The procedures described here are not theoretical. They address a compliance event that is actively affecting organizations worldwide.

1. What Happened on June 12, 2026

On June 12, 2026, at approximately 5:21 PM Eastern, the United States government issued an export control directive to Anthropic prohibiting foreign nationals from accessing two models: Fable 5 and Mythos 5. The prohibition extends to foreign Anthropic employees within the United States.

The directive cited national security authorities and referenced a method of bypassing Fable 5's safety mechanisms to analyze code for vulnerabilities. Anthropic characterized this as a routine capability present in all frontier models.

Because Anthropic cannot reliably verify the nationality of every user in real time at scale, the company disabled both models globally for all customers. All other Claude models remain available.

Key Facts

What This Means for Regulated Organizations

Any organization that was running Fable 5 or Mythos 5 in production on June 12 experienced an unplanned model transition. If that organization operates in a regulated environment, the transition is a compliance event that requires documentation, evidence, and -- in many frameworks -- notification.

2. Why Model Recall Is a Compliance Event

A model recall is not a service outage. It is a supply chain disruption with regulatory implications. The distinction matters because the evidence requirements are different.

Regulatory Framework Mapping

Framework Requirement Why Model Recall Triggers It
EU AI Act Art. 9 Risk management system must address foreseeable risks Model unavailability is a foreseeable risk. Organizations must document their response and fallback procedures.
EU AI Act Art. 17 Quality management system must include post-market monitoring A recalled model requires documented corrective action and evidence of continued system integrity.
NIST AI RMF GV-1.2 Organizations define and document AI risk tolerances A government-ordered model suspension tests whether the organization's risk tolerance documentation covers supply chain events.
NIST AI RMF MP-4.1 Model deployment decisions include risk assessment Transitioning to a replacement model requires a new risk assessment with documented rationale.
CMMC SI-7 Software, firmware, and information integrity A model change is a software change. Integrity monitoring must capture the transition.
SR 11-7 Model risk management A model recall is a model risk event. The organization must document the event, assess impact, and validate the replacement model.
NIST 800-53 SA-12 Supply chain risk management The model provider is part of the supply chain. A government-ordered shutdown is a supply chain risk event.

In every case, the requirement is the same: produce evidence. Evidence of what was running, evidence of the transition, evidence that the replacement meets the same requirements.

3. SWT3 Procedures That Apply

AI-REV.1

Anchor Revocation

The primary procedure for model recall events. AI-REV.1 mints a revocation anchor targeting the fingerprint of the recalled model's active anchors. Reason code 1 (model_recall) is specifically designed for government-ordered or provider-initiated model shutdowns.

The revocation anchor is itself immutable. It does not delete the original anchor -- it creates a new record stating that the original anchor's model is no longer available. This preserves the full evidence chain.

Assessor tip: Query the ledger for all AI-REV.1 anchors with reason code 1. Each one should have a timestamp within hours of the directive. A gap between the directive timestamp and the revocation timestamp represents unwitnessed exposure.
AI-MDL.2

Model Versioning and Selection

Provides the evidence of what model was running before the recall. Every inference witnessed by SWT3 records the model identifier in Factor A. An auditor can query the ledger for all AI-MDL.2 anchors with claude-fable-5 or claude-mythos-5 to determine the exact scope of exposure.

Assessor tip: The last AI-MDL.2 anchor for the recalled model establishes the cutoff time. Compare this against the directive receipt time to determine whether any unwitnessed inferences occurred during the gap.
AI-SAFE.1

Safe-State Transition

Witnesses the transition from the recalled model to its replacement. Records the trigger condition (export control directive), the transition type (forced model swap), and the resulting model state. This procedure creates the bridge between the revocation event and the new model deployment.

Assessor tip: Every AI-REV.1 anchor should have a corresponding AI-SAFE.1 anchor showing the transition to the replacement model. Missing pairs indicate the transition was not witnessed.
AI-SUPPLY.1

Supply Chain Attestation

Documents the supply chain state after the recall. Which providers are still available? Which models are still accessible? Has the organization verified that the replacement model meets the same compliance requirements as the recalled model?

Assessor tip: Request the AI-SUPPLY.1 anchor minted after the recall event. It should list the provider, the replacement model, and attestation that the replacement was evaluated against the same requirements.
AI-BASE.1

Behavioral Baseline

A replacement model has different behavioral characteristics than the recalled model. Token distributions, latency profiles, output patterns, and error rates will differ. AI-BASE.1 establishes a new baseline for the replacement model so that drift detection has a valid reference point.

Assessor tip: The baseline should be established within 48 hours of switching to the replacement model. Late baselines mean early anomalies are baked into the reference, reducing the value of subsequent drift detection.
AI-DRIFT.1

Drift Detection

Monitors the replacement model for behavioral divergence from its established baseline. After a forced model transition, drift detection is critical because the organization did not choose the timing of the switch. The replacement model may behave differently under the same workloads.

Assessor tip: Review drift scores for the first 7 days after the model transition. Elevated drift during this period is expected, but sustained drift beyond the first week may indicate the replacement model is not suitable for the workload.

4. Incident Response Playbook

This playbook assumes the organization is already using SWT3 to witness AI inferences. If the organization was not witnessing before the recall, it can still begin witnessing now to document the transition and replacement model behavior.

Step 1

Mint AI-REV.1 Anchors for All Active Integrations

For every integration that was using the recalled model, mint a revocation anchor with reason code model_recall. This creates the formal record that the model has been withdrawn from service.

Include the directive reference, the timestamp of receipt, and the scope of the revocation in the observations field.

Step 2

Document the Directive

Record the following in your incident log:

Step 3

Switch to Fallback Model and Witness the Transition

Swap to your fallback model. Mint an AI-SAFE.1 anchor documenting the transition: which model was removed, which model replaced it, and the trigger condition (export control directive).

If your organization has a pre-defined model fallback plan, execute it. If not, this event demonstrates why you need one.

Step 4

Establish a New Behavioral Baseline

The replacement model has different output characteristics. Mint an AI-BASE.1 anchor establishing the baseline within 48 hours. This anchor becomes the reference point for all subsequent drift detection.

Step 5

Monitor for Drift on the Replacement Model

Enable AI-DRIFT.1 monitoring on the replacement model. Elevated drift scores are expected during the first 48-72 hours as the baseline stabilizes. Sustained drift beyond one week warrants investigation.

Step 6

Export Evidence Package

Generate a compliance evidence package containing:

This package is auditor-ready evidence that the organization responded to the recall event with documented procedures and cryptographic proof.

5. Code Examples

Revoking Anchors for a Recalled Model (Python)

from swt3_ai import witness

# Initialize with your tenant credentials
w = witness.SWT3Witness(
    tenant_id="YOUR_TENANT",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Revoke all active Fable 5 anchors
# reason=1 is model_recall
w.revoke(
    fingerprint="<last-fable-5-anchor-fingerprint>",
    reason=1,  # model_recall
    observations={
        "directive": "US export control, June 12, 2026",
        "affected_models": ["claude-fable-5", "claude-mythos-5"],
        "action": "Global suspension per provider compliance"
    }
)

Revoking Anchors for a Recalled Model (TypeScript)

import { SWT3Witness } from '@tenova/swt3-ai';

const w = new SWT3Witness({
  tenantId: 'YOUR_TENANT',
  endpoint: 'https://sovereign.tenova.io/api/v1/witness'
});

// Revoke with model_recall reason
await w.revoke('<last-fable-5-anchor-fingerprint>', {
  reason: 1, // model_recall
  observations: {
    directive: 'US export control, June 12, 2026',
    affected_models: ['claude-fable-5', 'claude-mythos-5'],
    action: 'Global suspension per provider compliance'
  }
});

Witnessing the Model Transition

from swt3_ai import witness
from openai import OpenAI  # or any replacement provider

# Wrap the replacement model
client = witness.wrap(
    OpenAI(),
    model="gpt-4.5-turbo",  # replacement model
    agent_id="fraud-detection-v3"
)

# First inference on the replacement is automatically witnessed
# AI-INF.1 + AI-MDL.2 anchors minted with the new model identity
response = client.chat.completions.create(
    model="gpt-4.5-turbo",
    messages=[{"role": "user", "content": "Test inference on replacement model."}]
)

6. Export Control and Clearing Levels

The June 12 directive is fundamentally about access control by nationality. SWT3 clearing levels and CJT (Compliance Jurisdiction Traceability) fields provide the mechanism for documenting and enforcing these restrictions.

CJT Fields for Export Control

CJT Field Export Control Use Example Value
jurisdiction ISO 3166-1 country code of the user or deployment "US", "DE", "CN"
legal_basis The regulatory authority for the access restriction "EAR", "ITAR", "export-control-directive"
purpose_class The intended use category "commercial", "defense", "research"
authorization_id Reference to the specific export license or exemption "EAR-740.17", "denied"

CJT fields survive all clearing levels (0 through 3). Even at the highest clearing level, the jurisdiction and legal basis of each inference remain in the witness record. This means an auditor can always determine whether an inference was subject to export control restrictions, regardless of how much detail was cleared from the payload.

Clearing Levels as Access Enforcement

Organizations subject to export control can use clearing levels to enforce data handling requirements:

7. Lessons for All Providers

The June 12 directive targeted Anthropic. The implications extend to every organization that depends on a frontier AI model.

Anthropic's own assessment: "If this standard was applied across the industry, we believe it would essentially halt all new model deployments for all frontier model providers."

What This Means

SWT3 Is Provider-Agnostic by Design

The witness protocol does not depend on any specific model provider. The same AI-REV.1 procedure that revokes an Anthropic anchor works for OpenAI, Google, Meta, Mistral, or any other provider. The same AI-SAFE.1 transition procedure works regardless of which model replaces which.

This is the value of an independent witness layer. When the model provider is the subject of the compliance event, the evidence cannot come from the model provider.

8. References