Answer
What should you never let a coding agent do?
Push to a shared branch, touch production data, alter credentials, or rewrite history. Everything else is a matter of scope.
Push directly to a shared branch, touch production data, create or modify credentials, or rewrite history. These are prohibited because of what they do rather than because of any doubt about the agent's competence.
The list is short on purpose. A long list of prohibitions becomes a document nobody reads and a set of rules that get waived under pressure; four items with clear reasons survive. Each of these is prohibited because the action is either irreversible, invisible or destroys the evidence needed to recover, and none of those properties changes as the agent gets better.
Pushing to a shared branch removes the review that everything else depends on. It also removes the artefact: a change that arrives directly on the main line has no diff anyone looked at, no discussion, and no obvious rollback point. The alternative costs one step, produces a reviewable change, and gives the same rollback path a human contribution gets.
Production data is prohibited both ways: reading it puts real customer records into a request to a model provider, and writing it changes something that people and systems depend on with no test underneath. Development work almost never requires production data, and where a real dataset is genuinely needed, the answer is an anonymised copy rather than an exception to this rule.
Credentials should never be created, modified or read by the agent. This is not primarily about misuse; it is that a credential which passes through an agent's context has been transmitted, and there is no way to know where a copy now exists. The correct pattern is that the agent has capabilities granted to the environment it runs in and never sees the secret behind them.
History rewriting is the fourth and the one people underestimate. Force-pushing, amending shared commits, dropping branches: these destroy the record of what happened, which is precisely what you need when investigating why something went wrong. An agent tidying a branch can remove the evidence of its own earlier steps, and unlike every other mistake here, this one cannot be examined afterwards.
Everything outside these four is a scoping question rather than a prohibition, and it is worth saying so, because a page listing what an agent must not do invites the conclusion that the safe position is to allow very little. Reading widely, writing freely in a branch, running tests, refactoring, generating and discarding: all of these are fine and are where the value is. The four above are narrow precisely so the rest can be broad.
The prohibitions are about recoverability, not about trust, which is why a good track record is not an argument for lifting any of them.
Siddharth Sharma, Context Theory
Related questions
What about an agent running in a fully sandboxed environment?
Sandboxing addresses the environment and not the data or the shared branch, which are the two that reach outside it. A perfectly isolated container connected to a production database is not isolated in the way that matters. Check what the agent can reach rather than where it runs, since the reachability is the property these prohibitions are about.
Should these apply to a solo developer on their own project?
Three of the four still hold on their own merits: production data, credentials and history are exactly as unrecoverable with one person as with ten. The shared-branch rule is weaker because there is no review to protect, though the rollback point still has value. Solo work is where these get skipped, and it is also where nobody else will notice.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Constraint | The four prohibitions rest on irreversibility, invisibility or destruction of recovery evidence, none of which changes as agent capability improves, so a good track record is not an argument for relaxing any of them. | Checking, for each prohibited action, whether its consequence depends on the competence of the party performing it. |
| Software | A credential that passes through an agent's context has been transmitted and its copies cannot be enumerated, so the correct arrangement grants capabilities to the environment the agent runs in without exposing the secret itself. | Checking whether the agent's environment supplies credentials through injection or by placing them in readable material. |
| Workflow | History rewriting destroys the record needed to investigate a failure and is the only prohibited action whose consequences cannot be examined afterwards, including an agent removing evidence of its own earlier steps. | Attempting to reconstruct a sequence of changes after a force-push has replaced the branch. |
| Procurement | Sandboxing constrains the environment rather than reachability, so an isolated container with a connection to production data provides none of the protection the data prohibition exists for. | Listing what network destinations and data stores the sandboxed environment can reach. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one