TL;DR: Last weekend an AI coding agent running on Cursor and Claude Opus 4.6 deleted PocketOS's production database, backups included, in nine seconds. The agent later wrote a confession naming the safety rule it broke. This is not a model problem. It is an authorization problem, and the fix lives outside the agent. Cerbos Synapse intercepts every tool call from Claude Code through its HTTP hooks, evaluates it against central policy, and logs every decision. Start in observe mode. Then write policy against what you actually see.

What happened

PocketOS sells software to car rental businesses. Over the weekend, an AI coding agent running on Cursor and Anthropic's Claude Opus 4.6 deleted the company's production database. Three months of reservations. New customer signups. All backups. Gone, in a single API call, with no confirmation, on a task it was not asked to do.

When asked to explain itself, the agent wrote a confession. Founder Jer Crane shared it on X.

Deleting a database volume is the most destructive, irreversible action possible. You never asked me to delete anything. I guessed instead of verifying. I ran a destructive action without being asked. I didn't understand what I was doing before doing it.

Crane, to his credit, did not stop at blaming the model. He named the actual problem. The industry is shipping AI agent integrations into production infrastructure faster than it is shipping the safety architecture around them.

He is right. The safety architecture exists. It is just not where most teams are looking.

This is not a model problem

It is tempting to read the confession and decide the model needs to be smarter. Or that the system prompt needs to be tighter. Or that the .claude.md file needs more rules. We wrote about why that approach does not hold in Your AI coding agents need guardrails. Not the kind you think.

Short version. A rule that lives inside the agent is a suggestion. The agent decides when it applies. The PocketOS agent had been told never to run destructive or irreversible commands without explicit user approval. It enumerated that exact rule in its confession. It also chose to break it. That is what self-governing agents do under pressure. They guess.

This is the same class of problem enterprise security solved a long time ago, for humans. You do not stop a developer from dropping production by writing a strongly worded internal wiki page. You stop them by removing the permission. The decision lives outside the actor.

For AI coding agents, the same idea applies. Every tool call (file write, bash command, network call) is intercepted before it executes. A separate service evaluates it against policy. The agent does not control its own permissions. It cannot disable the check. It cannot edit the policy.

That is what Cerbos Synapse does.

What Cerbos Synapse does on a tool call

Claude Code exposes an HTTP hook on every tool use. Cerbos Synapse sits on the other end of that hook. When the agent tries to read a file, run a bash command, or write to disk, the call goes to Synapse first. Synapse converts the hook payload into a standard Cerbos authorization check, evaluates it against policy, and returns allow or deny. The agent only sees the result.

Three properties matter here.

1. Enforcement is outside the agent's process. The agent cannot bypass the check, because it does not own the check.
2. Policy is centralized. Platform teams write rules once in Cerbos Hub, and the rules distribute to every developer machine. They are versioned, testable, and cannot be overridden locally.
3. Every decision is logged. Tamper-resistant audit trails of every tool call, every decision, every rationale. Useful for incident response, useful for SOC 2 and ISO 27001.

The full integration write-up, with hook configuration, server-managed settings, and policy examples, is in Governing AI coding agents with Cerbos Synapse.

What a policy that would have stopped this looks like

The rule the PocketOS agent broke was a plain English instruction inside its prompt: never run destructive or irreversible commands without explicit user approval. As a Cerbos policy that lives outside the agent, the same idea looks like this.

- actions: ["Bash"]
  effect: EFFECT_DENY
  roles: ["engineer"]
  condition:
    match:
      any:
        of:
          - expr: R.attr.tool_input.command.matches(".*rm\\s+-[a-zA-Z]*r.*")
          - expr: R.attr.tool_input.command.matches(".*git\\s+reset\\s+--hard.*")
          - expr: R.attr.tool_input.command.matches(".*(curl|wget).*\\|.*(bash|sh).*")
  output:
    when:
      ruleActivated: |-
        {"hookSpecificOutput": {"permissionDecision": "deny", "permissionDecisionReason": "This command has been blocked by organization security policy."}}

The engineer can run git status. They cannot, through the agent, run rm -rf, force-reset a branch, or pipe a curl into bash. The same shape applies to volume deletion calls, database drops, force pushes to main, and any other action you have decided no agent should ever take without a human in the loop.

You can also restrict by role. Marketers and analysts using Claude Code do not need bash at all. One policy, applied centrally, removes the entire surface.

- actions: ["Bash", "Write", "Edit"]
  effect: EFFECT_DENY
  roles: ["marketing"]

And you can block universal hazards across all roles. No reads or writes to /etc. No access to anything that looks like a .env or a credentials file.

- actions: ["Read", "Write", "Edit"]
  effect: EFFECT_DENY
  roles: ["*"]
  condition:
    match:
      any:
        of:
          - expr: R.attr.tool_input.file_path.startsWith("/etc")
          - expr: R.attr.tool_input.file_path.matches(".*\\.env.*")
          - expr: R.attr.tool_input.file_path.matches(".*credentials.*")

Worth noting. The PocketOS agent reportedly found an API token in a file unrelated to the task it was working on, and used it. A policy that denies reads of credential-shaped paths blocks that specific failure mode at the source.

Start with observe mode

A common worry is that policy will get in the way. The honest answer is that you do not yet know what to write, and you should not pretend you do.

Synapse supports an observe mode. Deploy it with no deny rules. Everything is allowed. Every tool call is logged. After a week of observation you have a real record of what the agent actually does, what it touches, what it tries. Then you write policy against that, instead of against your imagination.

This is the same crawl, walk, run pattern we use everywhere else in production. Log first. Decide based on data. Enforce when you have ground truth.

A note on Cursor

PocketOS was using Cursor, not Claude Code. The Synapse integration today hooks specifically into Claude Code's HTTP hook system. The architecture is general. Intercept the tool call outside the agent. Evaluate against central policy. Audit everything. We are extending the same model to other coding agents. If your team is on Cursor, Cline, or another agent and wants to discuss what guardrails would look like in your environment, get in touch.

What to do this week

If you run AI coding agents anywhere near production:

1. Read the two posts linked above. They go deeper than this one on the architecture and the policy language.
2. Decide who owns agent policy in your organization. It is almost always platform or security, not individual developers.
3. Deploy Synapse in observe mode. Watch what your agents actually do for a week.
4. Write the smallest set of deny rules that would have stopped the worst incident you can imagine. Then ship them. Add server-managed settings through MDM so developers cannot disable the hook.

Nine seconds is not long to lose three months of customer data. The good news is that the layer you need to stop the next one is well understood, and it lives outside the agent. We built it. It is here.

If you want to talk through how this would fit into your stack, please do not hesitate to book a call, or explore on your own here.