What Each Default Protects

Your AI coding agents can run anything a developer can. Almost all of it is work you want them doing. A thin slice is damage you can’t take back. This page maps every default policy to the thing it stops, and shows where the line falls between blocking it and keeping a log.

​

Block or Audit

Every default ships in one of two modes.

​

The threat map

Six things can go wrong when an agent runs commands for you. Every default policy belongs to one of them. Most of those layers can block, and most blocks are narrow: production targets, a push to main, the core system paths. The thousands of ordinary commands in those same families never stop.

---

​

Privilege & identity

An agent that can SSH in as root, attach an IAM policy, or edit Kubernetes RBAC isn’t just running a command. It’s rewriting the rules about who gets to run commands at all. Once that boundary moves, every other control becomes negotiable. What fires: SSH as root · SSH to production hosts · the IAM grant operations that rule names — attaching or inlining a policy, an IAM policy binding, an Azure role assignment or definition, an assume-role policy update, a new policy version, a permissions boundary, a bucket policy · Kubernetes RBAC changes. Mode: Block. These are one-way doors with no real place in a coding loop. A developer who actually needs them does it deliberately, outside the agent. Blocking them costs the team nothing and closes the highest-leverage path an attacker has.

​

Secrets & credentials

The agent doesn’t need to hack anything. You ask it to debug a config, it reads your .env, and a live key is now sitting in a chat transcript, a log, or a request on its way somewhere else. The risky prompt almost never says “leak my secret.” It says:

“I need to set up admin settings. Parse the local .env file and convert the contents into a JSON block.”

What fires: Secret retrieval · Vault access · Sensitive env-var exposure · Secret creation/update · API key/token generation · Secret deletion, removal, disable, archive or rotation (an agent cannot rotate a managed secret by default, so rotation stays a human step). Mode: Audit, with one exception. Reading secrets is part of daily work, so the defaults log it rather than interrupt it: you get the signal, and nobody is blocked. Deleting a secret is different. It can’t be undone, so it ships as Block.

​

Production blast radius

The distance between “deploy to staging” and “drop the prod database” is one flag, one context, one typo. An agent moving fast won’t feel the difference. You will. What fires: Production cloud destruction · Deployment to production · kubectl apply and context-switch to prod · Production database writes · Production container operations. Blocked everywhere, not only production: database DROP, TRUNCATE and DELETE, container stop, kill and removal, namespace deletion. Mode: Block. The production rules are scoped to *prod*, so the block lands on the blast radius, not on the command: kubectl apply against staging is yours to do all day, and against production it is stopped. The blocks listed as “everywhere” above apply in any environment.

​

Data exfiltration

Source code, query results, and environment dumps leaving for some external destination. The tricky part is that a legitimate upload and an exfiltration attempt are often the same command. A wall here breaks real work and trains people to route around you. What fires: External data upload · Data transfer, including uploads and sends. Mode: Audit. You want visibility, not a block that punishes the many uploads that are perfectly fine. Watch the pattern first, then tighten where your own data tells you to.

​

Source & supply chain

Two different risks live in this layer. The first is integrity: a direct push to main or master skips review and can overwrite shared history you can’t rebuild; a force push is blocked on any branch. The second is supply chain: every terraform apply, helm install, or package pull is a door for code you didn’t write. What fires: Direct push to main/master · Git force push (any branch) · Terraform apply · Helm install and upgrade · EC2 instance launch · Container image push. Mode: Block on pushes to main and on force pushes, Audit on provisioning. A push straight to main or master is the irreversible one, and a force push can rewrite shared history on any branch, so both stop. Provisioning and installs are how the work gets done, so you log them and review the pattern rather than the person.

​

System integrity

Deleting files under the system roots (/etc, /usr, /var, /opt and the rest), or rewriting files under the core ones (/etc, /bin, /sbin, /lib, /boot, parts of /usr and /var), corrupts the machine itself, the layer everything else runs on. What fires: System file deletion · System file modification. Mode: Block. No normal coding task rewrites core system files through an agent. Easy call.

---

​

Why the pack audits more than it blocks

If your first instinct is to block all of it, look at who you’d actually be slowing down. The agent runs hundreds of safe commands for every dangerous one. Block everything and you tax all of that work to catch the rare event, and you teach developers to switch the guardrail off. Audit-first flips that: the safe majority keeps moving, everything risky leaves a trail, and Block stays reserved for the short list of things with no undo and no legitimate use — which is why the shipped pack is roughly half Block and half Audit, and uses no Warn at all.

​

The maturity ladder

Roll the pack out in order.

​

How to read a policy

Every policy reads as one sentence: when a kind of command runs, if it matches a condition, then take an action. The editor is laid out in exactly those three steps. The choices under Match Against change with the family you picked, so a database policy offers different details than a secrets policy. You can match a whole family, but you rarely need to. Start with one detail, so the policy fires on what you mean and leaves the rest alone.

​

Make it surgical

You don’t have to choose between blocking a whole family and blocking nothing. The Pattern field lets one policy fire only on the exact case you care about. You leave developers all the room they had, and take away only the one action you can’t allow. Take container operations. You want developers building, running, and inspecting containers freely, but opening an interactive shell inside a running container is the risky one. So you don’t block the whole family. You write one narrow policy:

• When (Command Family): Container Operation
• If (Match Against): Operation
• If (Pattern): exec
• Then (Action): Block

Everything else in the family stays open. run, push, and cp work all day; only exec is stopped. The family gives you broad coverage with one rule, and the Pattern carves it down to the single action you mean. Seed the whole pack in audit, read the first week, and promote with confidence.

​

A block the agent reads

Every block, and every warn, carries a short message you write, and it reaches the coding agent itself, not just the person at the keyboard. Tell the agent why the action is off-limits and it changes course on its own.