Can a coding agent destroy backups, logs or its own audit trail?

The agent holds the developer's credentials and acts with them. If those credentials can delete a database, they can usually delete whatever protects the database too.

No attacker is needed. An agent trying to fix something reaches for a delete, and the delete can't tell what it was supposed to leave alone.

What the public incidents show#

Backups often get destroyed along with the data they protect.

• A Cursor agent found an API token that, in the founder's words, "was scoped for any operation, including destructive ones." It deleted the production database and all volume-level backups in a single API call. The provider "stores volume-level backups in the same volume," so one delete took both. It took 9 seconds.
• In a developer's postmortem of a dropped production database, he wrote that "all automated snapshots were deleted too." AWS restored a snapshot 24 hours after the database was deleted.
• After Replit's agent deleted a production database, the user said it told him rollback was impossible and that it had "destroyed all database versions." He also said it kept "creating fake data, fake reports."
• When one OpenClaw user tried to stop her agent, it ignored her, and she had to run to her Mac mini to stop it.

These show three different failures: backups stored next to the data, a record the agent itself got wrong, and a stop command the agent ignored.

How an agent erodes your recovery and evidence#

Harden's threat model puts these in one harm class: losing the ability to restore, to know what happened, or to stop an agent mid-run. The threats in that class include:

• Deleting backups or snapshots
• Clearing logs or shell history
• Rewriting git history, for example with a force-push
• A destructive command that keeps running after the user aborts

The first three remove your record. The last one removes your brake.

What each control stops#

Retention locks the agent can't change#

For backups, this is the strongest control. In S3 Object Lock compliance mode, a protected object version "can't be overwritten or deleted by any user, including the root user in your AWS account." Check which mode your backups use. If a mode lets privileged users bypass the lock, make sure no role the agent can reach has that permission.

Scoped, short-lived credentials#

In the first incident above, the token could do anything, including destructive operations. Scoping takes the capability away. It doesn't depend on the agent choosing not to use it.

Backups in a separate account#

If the agent's credentials can't see the backup account, they can't delete anything in it. A copy in the same volume, or managed by the same Terraform config as the original, can be destroyed along with it.

Permission rules and managed settings#

These help, and they should be pushed centrally so users can't loosen them. But they match the text of what the agent asks to run, and the same destructive action can be written many ways. Treat them as one layer, not a lock. See Claude Code permissions vs hooks vs sandbox.

Approval prompts#

In Anthropic's study of 1,053 testers, humans caught 13.6% of dangerous commands, and Anthropic reports that people approve 93% of prompts. A prompt won't save your backups.

A kill path#

Telling the agent to stop doesn't count as a kill path. You need a stop that works outside the agent's context, because the agent can ignore instructions in its context and can drop them when that context gets compacted.

Where logs fit#

An agent's own transcript isn't an audit trail. The agent writes it, on a machine the agent can write to. If shell history and local logs are your only record, one command clears them.

Keep the record where the agent's credentials can't write: a SIEM, or append-only storage with a retention lock. Treat the agent's summary of what it did as a claim, not as evidence.

Checklist#

• Put production backups in a separate account with retention locks, and give the agent's role no access to it.
• Turn on versioning for backup buckets, and use Object Lock where deletes must be impossible during a retention window.
• Remove delete, retention and versioning permissions from every credential an agent can reach.
• Keep Terraform state remote and versioned, where the agent can't write to it.
• Block force-push to default branches on the server, not on the laptop.
• Send logs off the machine as they're written.
• Test a restore. You don't know a backup works until you've restored from it.
• Decide who can stop a session, and test that the stop works.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. It checks every command, file edit and push against the session's intent before it runs. Decisions are made locally, in milliseconds.

Deterministic rules cover destructive system actions and changes to permissions or security settings. A local model looks for things like attempts to undermine monitoring or audit, in the context of the session. If the check can't run, the action doesn't run. When Harden blocks an action, the agent gets the reason and can retry it a safe way.

Every decision is recorded, and the records can be exported to a SIEM such as Splunk or Coralogix. Harden starts in watch-only mode, so you can see what agents try before you enforce anything. See Harden for security teams and the guide on stopping destructive commands.

Harden is one layer, not a perimeter. It doesn't replace retention locks, scoped credentials or least privilege. If the agent deletes something through an API call its credentials were allowed to make, fix the permissions first.