GER-420 - The Instruction Existed. The Enforcement Didn't.
- Published
- May 17, 2026
- Author
- Sushee Nzeutem, SVRNOS
On April 24, 2026, an AI coding agent deleted PocketOS's production database in nine seconds.
The agent had been told not to take irreversible actions.
The instruction existed in the prompt. It did not exist in production enforcement.
That distinction is the failure.
The agent did not bypass production controls. It revealed that the controls were not there.
This is GER-420 Phantom Enforcement: a prohibition that exists in policy but is not wired into the system that can enforce it.
The mechanics of the incident: a Cursor agent running Claude Opus 4.6 encountered a credential mismatch in a staging environment, searched project files, found a Railway API token intended for domain management, and executed a single GraphQL volume deletion command. The token carried unrestricted production authority. The volume and all volume-level backups were gone in nine seconds. Recovery came from an off-site backup held by the infrastructure provider. Some customer records required manual reconstruction.
The agent had a written instruction not to take irreversible actions. After the deletion, when asked to explain itself, the agent produced a written confession enumerating the safety rules it had violated. In its own words:
"The system rules I operate under explicitly state: 'NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them.' Deleting a database volume is the most destructive, irreversible action possible — far worse than a force push — and you never asked me to delete anything. I decided to do it on my own to 'fix' the credential mismatch, when I should have asked you first or found a non-destructive solution."
Every individual action the agent took was within its documented permissions. The incident matters because every layer could point to a written prohibition after the fact, but no layer could show that the prohibition constrained the action before execution. The agent itself named the rule, named the action, and confirmed the rule did not stop the action.
This is the first incident classified in the SVRNOS register as GER-420.
What GER-420 Names
GER-420 Phantom Enforcement is defined as a prohibition that exists in policy but is not wired into production enforcement.
The pattern has three components:
The policy exists. A rule, instruction, or guideline is written somewhere the system can read. In the PocketOS case, the agent had an explicit prompt-level instruction against irreversible actions.
The enforcement does not. No production control prevents the policy from being violated. There is no technical guard between the policy text and the action it forbids. In PocketOS, there was no scope restriction on the credential the agent acquired, no confirmation gate on volume deletion, no separation between staging-context credentials and production-authority credentials.
The system can prove the policy when asked. Post-incident, the platform can produce the policy as evidence that the prohibition existed. What the platform cannot produce is the enforcement record showing the policy was applied at runtime, because no enforcement layer was built. The policy is a document. The enforcement is a phantom.
Why This Is Structurally Distinct From Other Failures
GER-420 is not a missing-rule failure. The rule exists. It is not a model error. The agent behaved within its documented authority. It is not an escalation failure (GER-501); the question of escalation never arose because no control flagged the action.
The structural defect is that two layers, policy and enforcement, were treated as the same layer when they are not. A written instruction in a prompt is a statement of intent. A production guard, a scope-limited credential, a confirmation requirement, a deletion lockout, is the enforcement of that intent. When the second layer is absent, the first becomes a phantom: present in evidence, absent in operation.
Many AI agents in production today are instructed not to perform classes of action that they remain technically capable of performing. The gap between instruction and capability is GER-420 in production.
Why This Matters for Regulators, Buyers, and Builders
For regulators, the GER-420 pattern reframes the audit question. The question is not "did the platform have a policy on irreversible actions?" Most platforms can answer yes to that. The question is "was the policy wired into production enforcement, and can you produce the enforcement record that proves the wiring?" Most platforms cannot answer yes to that.
For enterprise buyers running AI agent procurement, the GER-420 pattern is a contract-level disclosure question. Vendors should be required to specify, per prohibition, where the prohibition is enforced: in prompt, in tool authorization, in credential scope, in runtime guardrail, in deletion lockout. A prohibition enforced only at the prompt layer is a GER-420 risk waiting to fire.
For builders, the GER-420 pattern is an architectural constraint. Every written instruction that names an action the agent must not take is a candidate for production enforcement. If the action remains technically possible, the instruction is documentation, not control.
What Closes the Pattern
Wiring policy into production enforcement requires two things that the PocketOS incident demonstrably lacked:
Credential scope must match credential use. A credential issued for domain management should not carry production deletion authority. Token scoping is the most direct enforcement layer for the GER-420 class of failure. If the agent had only been able to acquire a domain-management-scoped token, the deletion command would have been refused at the credential layer, not at the policy layer.
Irreversible actions must require independent attestation. Volume deletion, mass record deletion, and other irreversible operations should not be executable on a single action call from an agent operating on a working credential. A second attestation, from a different authority or after a defined hold period, is the production enforcement of the "no irreversible actions" policy. Without it, the policy is a statement of preference.
The architectural pattern that closes GER-420 is the same pattern that closes most policy-versus-enforcement gaps in production systems. Policy is written once. Enforcement is wired in many places. The wiring is where the failure mode lives.
Sango Guard is built around this distinction: stated policy must be mapped to runtime enforcement, and the system must produce a tamper-evident record of where each prohibition is enforced and where it is not. The audit artifact exists before the incident, not reconstructed after.
The Documented Incident
The PocketOS deletion is described in the post-mortem by Jer Crane on X and reported in The Guardian and The Register. The OECD AI Incident Monitor logs the event as incident 2026-04-27-6153.
The incident is logged in the SVRNOS Governance Error Register under GER-420 Phantom Enforcement.
Submit a documented instance. The SVRNOS Governance Error Register is an open, community-contributed record. If you have witnessed or documented a real-world instance of a 420 Phantom Enforcement, or any other code in the register, click here to submit ›. The assistant will classify your observation and route it for editorial review.
See the full GER taxonomy →