Insights

Your Coding Agent Is the Contractor You Never Vetted

A coding agent running in a developer’s shell gets the developer’s identity, keys and network. Regulated firms have written policy for AI in production; almost none of it mentions the machine the code is written on.

By Antony Coppellotti, founder and CTO, Gordion Solutions. 26 September 2026.

1. The contractor you met this morning

A contractor turns up on Monday. Good CV, fast, keen. Nobody has taken references. You hand them your laptop, still logged in as you. Your cloud keys are in the home directory. They can push to main. They can install whatever they like. Then you go to lunch.

No CTO would sign that off. Most of them already have. That is what a coding agent gets when it runs in a developer’s own shell: the developer’s identity, the developer’s keys, the developer’s network, and a work rate no human contractor could match.

Regulated firms have spent two years writing policy about what AI may do in production. Almost none of that policy mentions the machine the production code was written on.

2. Unvetted is not the same as malicious

The agent is not trying to hurt you. The problem is worse than that, because it is structural.

A language model has no reliable way to tell an instruction from you apart from an instruction in the material it is reading. It is all text. And a coding agent reads a great deal of text you did not write: the issue, the pull request comments, the README, the docs page it fetched, the stack trace, the source of every dependency it opened. Any of that can contain an instruction. Some of it eventually will.

So the agent’s real principal is whoever wrote the last convincing thing it read. You cannot take references on that. You can only limit what it can reach and check what it did. Which is exactly how you would treat a contractor you had not vetted, if you were being honest about it.

3. What it can actually reach

The honest inventory is short and uncomfortable. The agent can reach whatever the developer’s session can reach, and a developer’s session was never scoped to a task.

Nothing in that table is exotic. It is the ordinary power of a workstation. The only new thing is who, or what, is holding it.

4. Four boundaries, pointed at the workstation

I have written before about the four boundaries we put around an agent in production. They transfer to the development environment without modification. The workstation is just another runtime.

B1 Reasoning. Everything the agent produces is a proposal. A diff is not a change until something that did not write it says so. That something is not the agent’s own summary of its work, and it is not a test suite the agent wrote in the same session. It is tooling and a human, checking the diff, not the story about the diff.

B2 Tools. Minimum access, credentials that expire. The agent runs in a container, not your shell. It sees the repository it is working on and nothing else. There are no cloud keys lying around in its environment; if the task needs one, it gets a token scoped to that task that dies when the task does. Network egress is an allow-list. It cannot push to a protected branch. Not should not. Cannot.

B3 Runtime. Deterministic code brackets the model. The agent decides what to attempt. Code that cannot be argued with decides what is permitted. Allow-listed commands. Hooks that refuse writes outside the working tree. A secrets check before every commit. A CI pipeline that is the only road to a shared branch, and which the agent has no way to edit. If the model can talk its way past a control, it is not a control.

B4 Oversight. A named human owns the policy. Someone specific decides what agents may do in your engineering estate, writes it down, and reviews it when it stops being true. Every command the agent runs is logged somewhere the agent cannot touch. And there is a stop that halts every agent session at once, which has been pressed at least once on purpose.

Notice what is missing. There is no line that says a developer reviews everything the agent does. Developers already cannot, and the ones who say they do are sampling.

5. The supply chain was already the weak point

Dependencies were the softest part of most software supply chains before any of this. Agents make three things worse.

They add libraries without hesitation. A developer pauses before pulling in a new dependency, because they know it is someone else’s code, someone else’s maintainers, and an install script that runs with their privileges. An agent does not pause. It reaches for whatever shortens the path to green.

They invent package names. Models suggest libraries that do not exist, and they suggest the same plausible names again and again. Register the name, wait, and eventually an agent will install what it believed should be there.

They read dependency code as instructions. A comment three levels down the dependency tree can steer the agent as effectively as an issue on your own repository. You did not vet that maintainer either.

The controls are boring, which is the point. Pin versions. Commit lockfiles. Install only from a registry you control. Block install scripts by default. Treat a lockfile change as a security review rather than noise in a diff. None of it is new. The agent just removed the human hesitation that was quietly standing in for it.

6. The soft underbelly

The development environment has always been the most privileged place in the estate. It holds the credentials, the source and the road into production. For twenty years we secured it by trusting the people who sat there, and mostly that worked.

An agent is a new person at that desk, and it is one you cannot vet. Banning it does not help; it moves the work to a laptop you cannot see. What helps is the same thing that works in production. Treat the output as a proposal. Give it the minimum it needs and take it back when the task ends. Put rules around it that it cannot argue with. Name the human who owns the policy and the stop.

Give the contractor a desk, a scoped badge and a supervisor. Do not give them your laptop.

If your AI policy covers production and says nothing about the machines where the code is written, that gap is what the Health Check finds. Start with the free Agentic AI Readiness Check, or get in touch with any questions on this article, or anything else.