Treat Coding Agents Like Untrusted Contractors

The strongest gap-filling signal for June 29 was Marius Hobbhahn’s argument that coding agents should be treated as untrusted by default, amplified through Digg’s Tech cluster. The important point is not abstract AI risk. It is the present-day mismatch between agent capability and deployment discipline: shell access, internet access, internal systems, and long autonomous runs are being combined faster than most teams are redesigning controls.

Product builders are now making security architecture decisions when they choose agent permissions, default tools, and execution environments. If you treat an agent like a helpful autocomplete, you will overgrant it. If you treat it like an energetic external contractor, you start making better choices about isolation, credentials, and review.

Write an explicit trust contract for any coding agent workflow. Trigger: the agent can run commands, read sensitive files, browse the web, or touch third-party systems. Context: repository scope, secret boundaries, approved tools, network policy, and allowed side effects. Tools: sandbox or worktree isolation, short-lived credentials, approval gates, and audit logs. Verifier: tests plus a human review for any privileged action. Budget: cap runtime, write scope, and outbound connectivity. Artifacts: permission manifest, run log, changed files, and escalation note. Stop condition: the agent either completes within its contract or halts when it needs a privilege it was not given.

List every system one of your agents can currently touch. Then remove one permission and see if the workflow still works. If not, redesign the loop until it fails safer.