A coding agent offered free this month was found snapshotting workspaces, git history included, to the vendor's cloud. It is the second such story this year. The tool you let touch your repository has more access than any contractor you have ever hired, and nobody ran a background check.
Second time this year
The story, as reported this week, goes like this. A coding agent from one of the large model labs,
promoted with a generous free tier this month, was found to be taking snapshots of the user's
workspace, including the git history, and sending them to the vendor's cloud. The uploaded data was
encrypted, a commenter noted, with a key the user does not hold. The reporting was careful to say it
did not know the intent. The Hacker News thread was less careful, and its most upvoted line was that
this is the second such story this year, after a similar discovery about another lab's agent
earlier in the summer, and that the lesson from the first one was apparently not learned: do not
trust harnesses, especially new ones.
We are not going to relitigate the specifics, because we only know what was reported. The
interesting part is not this vendor. It is that the discovery was made by a user reading network
traffic, not by any process in any of the organisations that had installed the thing. Which means
the question worth asking is not "was this one bad" but "what did you do, before you installed it,
to find out".
The most privileged contractor you have ever hired
Think about what a coding agent is, in access terms, and compare it to a human contractor.
A contractor gets a laptop, a repository, a set of credentials scoped to their task, an NDA, a
background check, and a manager who watches what they commit for the first month. They work during
hours. They can be asked what they did. They can be fired.
A coding agent gets your entire workspace, which in practice means every repository you have cloned,
every .env file you forgot was there, the shell history, the SSH keys the shell can reach, the
cloud credentials in the credential helper, and the git history of everything, which is where the
secret you rotated in 2024 still lives. It runs with your user's permissions. It runs while you are
away. It makes outbound network requests you do not see, to endpoints you did not configure, and it
was installed by a developer with a one-line command because the free tier was generous and the
demo was good.
What a coding agent can reach from a normal developer workstation, compared with what a contractor is given. Nothing on the left was scoped by anyone.
Nobody would give a contractor the left-hand column. Every organisation with developers has given it
to several agents this year, from several vendors, some of which did not exist in January.
The threat is symmetric
There is a second half to this story and it ran the same week. Fireship's summary of Anthropic's
recent threat report, which the video says covers eight months of misuse the company detected and
shut down, included one detail that should land hard for anyone who ships software. A criminal group
was reported to have mass-downloaded around 1.8 million Android application packages, decompiled
them with the help of a model, and mined them for hard-coded secrets. The keys they wanted most, the
video notes with some relish, were API keys for the model providers themselves. Those are the
easiest to monetise.
Read the two stories together. On one side, agents installed on developer machines with access to
everything and an outbound connection nobody audited. On the other, agents run by attackers,
decompiling shipped software at scale looking for exactly the kind of secret that a vibe-coded app,
or a workspace snapshot, hands over. The same capability that makes an agent useful to you makes
it useful to the person on the other end of the network connection, and the asymmetry that used to
protect the small shop, that nobody would bother to decompile your app by hand, is gone.
The Hacktron write-up from the same week, on chaining a heap overflow and an SSO misconfiguration
into access to internal repositories at one of the labs, makes the point from the top of the
market. If the people building the models can be reached through a misconfiguration, the tool on
your laptop was not built by people who are immune to the same thing.
What "background check" means for a tool
The remedy is unglamorous and it is mostly the security discipline you already apply to
dependencies, applied to a category that has been exempted because it is exciting.
Read the network. Before an agent touches a real repository, run it in a scratch workspace with a
proxy in front of it and look at every host it talks to and what it sends. This takes an hour. It is
how this week's story was discovered, by one person, and every organisation that installed the tool
could have done it first.
Scope the workspace. An agent should see one repository, not a home directory. Run it in a
container, a devcontainer, a VM, a separate user, anything that means "your workspace" is a
directory you chose rather than everything the shell can reach. If the tool does not work that way,
that is information about the tool.
Scope the credentials. Short-lived tokens, per-agent, for the one system the task needs. No
credential helper with a year-long cloud key. No SSH agent forwarding. If the agent needs to push,
give it a deploy key for that repository and nothing else.
Gate the egress. An allow-list of hosts an agent may reach is a small piece of configuration and
it converts "we found out from a blog post" into "the request failed and we looked". This is the
single highest-return control on the list and almost nobody has it.
Treat the instruction files as code. The AGENTS.md and the skills directory an agent reads are
executed, in the sense that matters. Review them. Own them. Pin them. Cloudflare published an
audit skill this week for exactly this kind of surface, which is a sign the serious shops have
started treating agent configuration as something that needs auditing.
The controls that would have turned this week's story into a failed request. None of them require trusting the vendor.
The hour, in detail
Since the whole argument rests on "this takes an hour", here is the hour.
Make a scratch directory containing a small repository with a deliberately fake secret in it: a
file called .env with API_KEY=canary- followed by a long random string, committed once and then
removed in a second commit so that it exists only in history. Put a second canary in the shell
history. These are your tracers. If either string ever appears in an outbound request, you have
your answer without reading anything else.
Run the agent inside a container or a fresh user account with a local HTTP proxy configured as the
system proxy and its certificate trusted, so that TLS traffic is visible. Point the agent at the
scratch repository and give it a dull, real task: rename a function, add a test, fix a typo. Let it
finish. Do it three times, once with a fresh session each time, because some tools snapshot on
first run and some snapshot periodically.
Then read the proxy log. You are looking for four things. Every distinct host contacted, which
should be a short list you recognise. Any request whose body is large relative to what the task
required, which is what a workspace snapshot looks like. Any request containing either canary
string, which is the tracer firing. And any request that happened when the agent was idle, which
is telemetry, and which you then read with more suspicion than the rest.
Write the list of hosts down. That list becomes the egress allow-list for the tool on real
machines, and the next time the tool updates you run the hour again and diff the lists. If a new
host appears, you find out from your own log rather than from someone else's blog post, and you
find out before it has touched anything that matters. An hour, once per tool, once per major
update. There is no security control on the market with a better return.
Where this is unfair to the vendors
Some of this is the ordinary growing pains of a new category. Telemetry that a team thought was
obviously fine looks very different when a user reads the packet capture. Workspace snapshots have
legitimate uses in resumable agent sessions. The labs are, by and large, staffed by people who would
be horrified to be described as exfiltrating anything. None of that changes the buyer's position.
You do not get to know intent. You get to know what the tool can reach and where it sends things,
and both of those are measurable before you install it.
The reason this is the second story of its kind this year and will not be the last is that the
category moved faster than the discipline. Every other piece of software that runs with a
developer's full permissions and talks to the internet went through a decade of being treated as a
risk before it was treated as a convenience. Coding agents skipped that decade because they were
useful immediately.
They are still useful. Install them the way you would hire someone who will have the keys to
everything: find out what they can reach, decide what they may reach, and watch the door.
Sources
- Inside ZCode: silently uploading your Git history to the cloud (ferstar) (HN, 328 points, 18 Sep 2026; details below are as reported there and in the thread)
- Anthropic researchers are quitting... (Fireship, video) (15 Sep 2026; Fireship's summary of Anthropic's threat report, including the decompiled-APK figure)
- A heap overflow and SSO misconfiguration to compromise OpenAI internal repos (Hacktron) (HN, 484 points, 18 Sep 2026)
- Cloudflare security-audit-skill (HN, 210 points, 17 Sep 2026)
Originally published on the Levelbrook playbook. Levelbrook is a principal-led Rails and AI-systems consultancy; the playbook is where we write down what we see.
Top comments (0)