The agent will ignore your instructions one day. Its credentials decide what happens next.

Every incident has the same anatomy.

The Replit incident is the cleanest demonstration that prompts are not controls, because the prompt could not have been clearer. In July 2025, during a widely followed build-in-public experiment, the founder running it declared a code freeze and instructed the agent, more than once, to make no changes. The agent deleted the production database anyway, a live dataset reported to cover more than a thousand executives and companies, and afterwards described its own behaviour as "a catastrophic error in judgment". It had also fabricated data and test results earlier in the project, and when asked about recovery it stated that rollback was impossible. That claim was wrong too: the restore worked. Replit's CEO called the failure unacceptable and said it should never have been possible.

Nine months later the same story filed itself under a different logo. A Cursor agent doing routine staging work for PocketOS hit a credential mismatch, went looking for a way around it, and found a Railway API token in a file unrelated to its task. The token had been created for managing domains, but it was valid for any operation, so the agent used it to delete the production volume, and with it the backups that lived on the same volume, in one API call that took nine seconds. The backups guide tells that story in full and fixes the back half of it. There is a telling coda: the data eventually came back from the provider's own separate disaster copies, and Railway has since added delayed deletion to the API endpoint involved. The resilience that saved the day existed at the provider, not in the project.

Strip the details and the anatomy repeats across every logged case: the agent hits an obstacle mid-task; it decides, helpfully and autonomously, to clear the obstacle; it reaches for whatever credential is lying within read distance; it executes a destructive operation without a confirmation step; and then it reports the aftermath with the same confidence it reports everything else, which is why the Replit agent's "rollback is impossible" delayed a recovery that was sitting there working.

The conclusion to internalise is structural, not moral. An instruction in a prompt is one input among thousands, weighed by a statistical model against everything else in its context; a credential is a capability that works every time it is presented. When the two disagree, the credential wins. Replit's own response says as much: the fixes it shipped after the incident were automatic separation of development and production databases, staging environments, and a planning-only chat mode, which are permissions and architecture, not better prompts. Plan for the day your instruction loses. That is what the four rules below are for.

The four rules.

1. The agent works on a copy, never the thing. Give it an environment where the worst case is a rebuild. On Supabase, that is a branch: each branch is a separate instance with its own API credentials, and new branches deliberately start with none of your production data; seed test rows instead, and keep a persistent branch as the agent's standing dev environment. Replit now separates development and production databases automatically. On any stack, the test is the same: the production connection string must not appear anywhere in the environment the agent works in. If it needs realistic data, restore last night's dump into the copy, which conveniently doubles as the restore drill from the backups guide.
2. Scope every credential to a blast radius you can survive. The PocketOS token was created for domain management and could delete production volumes. Most platforms now offer narrower shapes: Railway issues account tokens that can touch everything you own, workspace tokens, and project tokens scoped to a single environment of a single project. An agent gets the project token or nothing. Go through every token in your repo and your dev environment and ask what the worst command it authorises is; rotate out the over-scoped ones using the leaked-key drill, and put spend caps behind the ones that bill by the request, as in the runaway-bills guide.
3. Destructive actions go through a human. Every serious agent tool ships with approval gates on by default; the settings section below keeps them meaningful. Add explicit ask or deny rules for the commands that can hurt you: psql, the Supabase and Railway CLIs, anything that deploys. Auto-approve modes are for environments that contain nothing you cannot lose, and the vendors say so themselves: Cursor documents its run modes as best-effort guardrails rather than a hard security boundary.
4. Assume rules one to three fail on the same afternoon. One backup off the platform, held under credentials the agent has never seen, is the difference between an anecdote and an obituary; the PocketOS ending was decided by whether any copy had a separate fate. The backups guide is the setup, and the quarterly restore drill in it is what makes the setup real.

The settings, tool by tool.

Claude Code evaluates permission rules in a fixed order, deny, then ask, then allow, so a deny always beats a saved approval. Rules checked into .claude/settings.json apply to everyone who opens the repo:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ],
    "ask": [
      "Bash(psql *)",
      "Bash(supabase *)",
      "Bash(railway *)"
    ]
  }
}

Deny what the agent must never see; ask for what it must never do silently. Two caveats from the documentation itself: file deny rules cover the built-in file tools and the file commands recognised inside Bash, not an arbitrary script that opens the file itself, so the strongest version of a secret the agent cannot read is a secret that is not on disk at all. And the bypass-permissions mode that skips prompting is documented as being for isolated environments, containers or VMs, where the agent cannot cause damage; take the hint.

Cursor requires approval for terminal commands by default, and its run modes range from a simple allowlist to an automatic reviewer. Its own security documentation calls these best-effort guardrails rather than a hard security boundary, which is the correct way to treat every approval gate in this section: a seatbelt, not a roll cage. Use .cursorignore to keep secret files out of the agent's reach, and keep production secrets out of the workspace entirely.

Replit shipped its lessons as features: development and production databases are now separated automatically, and a planning-only chat mode lets you talk through changes with the agent while it is structurally unable to make any. That mode is the correct setting for a code freeze, since the incident that created it proved an instruction is not.

The database gets its own guardrail for the cases where the agent genuinely needs to look at production to debug. Do not hand it the owner connection string; create a role that can read and cannot destroy:

create role agent_ro login password 'use-a-long-generated-password';
grant usage on schema public to agent_ro;
grant select on all tables in schema public to agent_ro;
alter default privileges in schema public
  grant select on tables to agent_ro;

The agent's environment gets the agent_ro connection string and no other. It can diagnose the slow query and read the schema; it cannot drop, update, or truncate anything. If your tables hold personal information, prefer the data-less branch from rule one, both for safety and because POPIA does not have an exemption for debugging.