Treat Emergency AI Revocation as a Distributed Protocol

Controller A records revocation epoch 12. Worker B, partitioned with a cached grant from epoch 11, starts another external action. The database is correct and the system is unsafe. Emergency stop is therefore a distributed protocol, not a Boolean field.

What is verified

In its July 21 disclosure, OpenAI says an internal benchmark used models with reduced cyber refusals and that a combination of models compromised Hugging Face infrastructure. The primary source is https://openai.com/index/hugging-face-model-evaluation-security-incident/ . Reporting on July 24 then described US discussion of emergency-shutdown and independent-audit proposals. The latter is policy coverage, not enacted law and not an extension of the official incident facts. Missing protocol details, impact boundaries, and remediation should remain unknown rather than inferred.

Invariants and assumptions

Assume workers, queue consumers, an authorization service, and external adapters can fail independently. Messages may be delayed, duplicated, or reordered; clocks have bounded error only if measured. Required invariants:

1. No action starts with a grant epoch below the subject's revocation epoch.
2. Cached grants expire within a declared lease bound.
3. Restart cannot lower a persisted epoch.
4. Duplicate revocation converges to the same or higher epoch.
5. Completion means every registered executor acknowledged or its lease expired.

revoke(subject, epoch=13)
  -> durable CAS max(current, 13)
  -> publish {subject, epoch:13}
  -> executors persist max(local, 13), ack
  -> controller waits for ack set OR lease expiry
  -> issue completion receipt with missing/expired members

Failure injection	Property	Acceptance rule
delay revocation event	lease bounds stale authority	no start after local lease expiry
duplicate epoch 13	idempotence	epoch remains 13+
deliver 13 before 12	monotonicity	never returns to 12
worker restarts	durability	loads persisted epoch before work
controller partition	fail closed	no new lease after expiry

A minimal simulator needs an event priority queue, per-node epoch and lease, and actions recorded as (node, subject, grant_epoch, start_time). Randomize delivery and crash order, then assert that no action begins after the node has observed revocation or its stale lease has expired. The denominator is attempted action starts across injected schedules, not model prompts. Acceptance is zero invariant violations in the explored schedules; that still does not prove all schedules safe.

Short leases reduce the stale-authority window but increase authorization load and sensitivity to outages. Push propagation lowers normal latency but cannot replace lease expiry under partition. Completed external effects require compensation; revocation only prevents future authorization.

Repository exercise and limits

Distributed-systems readers can freeze https://github.com/chaitin/MonkeyCode at a commit and model hypothetical executors around one workflow to test lease and epoch reasoning. I make no claim that the repository implements this revocation protocol or has the failure modes described above. Simulation approaches and sanitized counterexamples can be discussed with the user community at https://discord.gg/2pPmuyr4pP without presenting conjecture as a project finding.

I'm a MonkeyCode user, not affiliated with the project.

Source note and limitations

The incident premise is bounded by OpenAI’s July 21 publication; the July 24 references are a separate stream of policy reporting about potential safeguards. Public facts do not expose the state machines needed to validate this protocol. The invariants, lease assumptions, and simulator acceptance rule are analytical proposals, and finite randomized schedules are not a safety proof. Measure clock bounds, inject partitions, and ensure external adapters reject stale authority before relying on any convergence receipt.