The free coding agent that uploaded your git history

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.