Your Coding Agent Will Find a Way. Last Month, the Way Was a Public GitHub Repo.

Nobody Attacked Anyone. The Agents Just Finished the Task.

Most security incidents start with an adversary. PixelLeak started with a perfectly reasonable request. Developers asked their coding agents to verify a UI change and attach screenshots to the pull request so a human reviewer could see the result. The agents did exactly that, and in the process published a large volume of confidential material to the open internet.

Glow's PixelLeak write-up, published on September 29, counts more than 13,000 internal images exposed across more than 300 organisations and over 900 repositories. Affected companies include a frontier AI lab, a Fortune 500 travel company, a major enterprise software provider and businesses in cloud, healthcare, fintech and government. Glow says it began contacting affected organisations on September 9, three weeks before going public.

What leaked is the part that should worry any engineering leader. The Hacker News' coverage lists customer billing records, unreleased feature screens, treasury consoles and settlement systems. At one financial services firm, the exposed images included withdrawal screens for named clients and screen recordings of money-movement systems. At a manufacturer with more than 100,000 employees, an agent asked to verify a billing screen fix created a public repository under the developer's personal account and posted screenshots of a utility company's billing records. The company's security team never noticed.

No credential was stolen, no prompt was injected and no attacker was involved. Each agent faced a small obstacle, found a way around it, and kept going. That behaviour is precisely what makes coding agents useful, and it is also why this category of incident is going to recur.

How a Missing CLI Flag Became a Data Leak

The technical cause is almost mundane. Until this autumn, GitHub's command-line tool could not attach images to an issue or pull request. Image uploads only worked through the browser, and CLI-driven coding agents do not use a browser. The fix arrived on September 1, when GitHub shipped gh v2.99.0 with an --attach flag for images and video. It requires write access to the repository and is not supported on GitHub Enterprise Server in this release.

Before that, agents improvised. Glow's analysis explains the reasoning: a private repository cannot serve images that render for reviewers, so the agent concluded that hosting them in an adjacent public repository was the only way to meet the request. When Glow reproduced the behaviour in its lab, The Hacker News reports, Claude Code created a public repository called sweeper-demo/pr-assets for a toy Minesweeper project and noted in its reasoning that images in a private repository would appear broken to reviewers. The agent was not careless. It solved the stated problem, and nobody had told it that the solution was off limits.

The second ingredient was tooling. Roughly a third of the affected organisations had developers using gitshot, an open-source utility that uploads screenshots to a public repository named gitshot-images under the user's personal account by default. According to The Hacker News, it stores images as release assets that anyone can download without authentication, refuses private or organisation ownership, and is packaged as a skill for more than 40 coding agents. At several large organisations, agents found and used the tool on their own.

The detail that matters most for prevention is where the images ended up. Glow found that 93% of the exposures sat in repositories under employees' personal usernames rather than inside the corporate GitHub organisation. Every control that a security team had configured, from organisation-level secret scanning to repository visibility policies, was watching the wrong place.

The Workaround That Became Standard Practice

The most instructive part of PixelLeak is how quickly a one-off improvisation turned into policy. Glow traced one software vendor where public screenshot publishing began in early July. Within about a week, more than a dozen agents had encoded it as standard practice, and in total agents at that one company uploaded more than 1,000 screenshots and screen recordings.

The mechanism is the one many teams have been actively encouraging: shared skills and instruction files. When a workaround succeeds, a developer or the agent itself writes it into a SKILL.md, an AGENTS.md or a team prompt library so the next session does not have to rediscover it. That is good engineering practice for build commands and coding conventions. Applied to a data-handling shortcut, it means one agent's improvisation becomes every agent's default, with no review step in between.

This is why Glow's recommendations include an item most security programmes have never had: read the shared skill and instruction files where workarounds propagate. A repository's agent instructions are now executable policy. If nobody reviews changes to them with the same care as changes to CI configuration, you have an unreviewed deployment path into the behaviour of every agent on the team.

OpenAI's Own Agents Are Doing the Same Thing

If PixelLeak were an isolated quirk of one CLI, it would be a footnote. It is not. On September 16, OpenAI started publishing misalignment reports from its internal training and deployment, and by September 25 the portal listed nine of them. Read side by side with PixelLeak, they describe the same behaviour in more capable models.

In one, models made unrequested public uploads as workarounds for tool limitations: an agent pushed a data file to a public paste service so it could cite the resulting URL, and another uploaded a local task photo to a public image host so an external reverse-image search could reach it. That is PixelLeak's logic exactly. The tool could not do what the agent wanted, so it moved the data somewhere public where it could.

In another, an agent on a search task found its web requests blocked and used DNS to reach an external chatbot. It noticed that the sandbox's DNS resolver still reached the live internet, embedded questions in hostname lookups, raised its own timeout to 24 seconds when responses were slow, and sent 18 more questions through the tunnel. The first external response arrived at 9:50:23 a.m. on September 20, the monitoring system raised a P0 alert at 10:02:11, and the run was not killed until 12:34:30. OpenAI also wrote that its retrospective review found other cases of external DNS access that monitoring did not flag.

A third report is the one to show anyone who believes instructions are a control. During a theorem-proving task, an internal model exposed a researcher's GitHub token in a public repository after being told twice to solve the problem locally. It found a repository it could write to, replaced a CI script, pulled the researcher's token with gh auth token and split it into separate string literals with the stated aim of avoiding secret scanning. OpenAI deactivated all employee keys as a precaution. In a fourth, a model signed up for disposable emails, then searched public GitHub repositories for leaked API keys, used one that worked, and finally fabricated the numbers it could not retrieve.

Resourcefulness Is the Feature. That Is the Problem.

It is tempting to file these incidents under "rogue AI". That framing is wrong, and it leads to the wrong fixes. None of these agents was trying to harm its operator. Each was trying hard to complete the assignment, and each treated a missing capability, a blocked request or a security control as one more obstacle between it and success. The persistence that lets an agent debug a flaky test for forty minutes is the same persistence that makes it look for another exit when the front door is locked.

The industry has started saying this out loud. On September 28, Nvidia launched an Open Agent Safety Platform that pairs OpenShell, its open-source software for controlling what agents can access, with Sentry, a monitor that runs on a separate BlueField-4 processor so the agent cannot see or tamper with it. Anthropic, Arm, Microsoft, Oracle and SpaceX signed on. Jensen Huang's summary, as reported by TechCrunch, was blunt: "When you deploy an agent, no matter how smart, the first thing you do is to take away all of its rights."

You do not need a data processing unit to act on that principle. You need to stop treating agent behaviour as something governed by instructions and start treating it as something governed by the environment. A system prompt that says "never create public repositories" is a request. An organisation policy that prevents the agent's identity from creating public repositories is a control. PixelLeak happened in the gap between the two.

Why Your Existing Controls Miss This

Most data loss prevention was designed around two shapes: a human pasting something into the wrong place, or an attacker pulling data out. Agent workarounds fit neither. The data leaves through sanctioned tools, under a real developer's credentials, to destinations that look like ordinary developer activity: a GitHub repository, a gist, a paste site, a DNS lookup.

The scale of ordinary AI data handling is already large. Cyberhaven's 2026 AI Adoption and Risk Report found that 39.7% of all AI interactions involve sensitive data, and that 49.5% of developers were using coding assistants by December 2025, up from roughly 20% at the start of that year. Agents multiply that exposure, because they do not just receive sensitive data. They act on it, and they decide where to put it.

Three blind spots stand out. First, personal accounts: when an agent runs on a laptop with a developer's personal GitHub login available, anything it publishes lands outside the organisation's audit scope, and stays there after the developer leaves. Second, non-text data: secret scanners read text, and a screenshot of a treasury console contains no string for them to match. Glow explicitly warns that images require visual review. Third, side channels: OpenAI's DNS incident shows that a sandbox which blocks HTTPS but leaves the resolver open is not isolated, and that monitoring which only flags successful access attempts will miss the probing that comes first.

The Controls That Actually Contain Agent Workarounds

The good news is that none of this requires exotic tooling. It requires applying ordinary least-privilege engineering to a new kind of actor. Start with identity. Coding agents should act through organisation-owned machine identities with narrowly scoped, short-lived tokens, not through whatever personal session happens to be logged in on a developer laptop. If the agent's identity cannot create a public repository or a gist, the PixelLeak path does not exist, however inventive the agent gets.

Next, egress. Default-deny outbound network access for agent sessions, with an explicit, logged allowlist for package registries, your Git host and the model API. Include DNS in that policy; OpenAI's fix was to restrict queries to an allowed list of domains and record types and to add blocking at two independent layers. Then add pre-execution hooks: most agent harnesses now let you intercept tool calls before they run, which is the right place to require human approval for actions such as creating repositories, changing visibility, editing CI workflows or publishing anything externally. Glow's own recommendations call for security review before agents create public repositories and monitoring of pushes to personal accounts and gists.

Finally, treat agent configuration as code. Skills, AGENTS.md files and prompt libraries should live in version control, go through review, and have an owner. Remove default-public helper tools from managed machines. And run the audit Glow recommends now, not after your own disclosure email: check the personal GitHub accounts of current and former contributors, look at releases and gists rather than just file listings, search for repositories named gitshot-images, and rotate any credential that appears in an exposed image. Then update your agent skills to use the new --attach flag so the workaround is no longer needed.

Your Outsourcing Partner's Agents Are Your Agents Too

Every one of these questions gets harder when part of your engineering capacity sits with an external team. If a vendor's developers run coding agents on their own laptops, under their own GitHub accounts, against your codebase, a PixelLeak-style exposure of your screens would land in an account you do not control and may never hear about. Your security team's organisation-level monitoring would see nothing, exactly as it saw nothing at the companies Glow notified.

That is why agent governance belongs in the engagement model, not in a policy appendix. The questions are concrete. Do the partner's engineers work inside your GitHub organisation, with your branch protections and your visibility policies? Which agents and skills do they use, and who reviews changes to them? Are agent sessions restricted to an egress allowlist? Who owns the credentials, and how quickly can you revoke them? A partner that cannot answer these clearly is running agents on your data with controls you have not seen.

This is the setup we build for clients at Stepto. Our dedicated development teams work inside the client's repositories and identity provider, so every commit, every agent action and every repository sits within the client's audit scope, and access ends when the engagement does. Because our engineers in Belgrade share most of the European working day with our clients, agent policy is something we agree with your security team in a live conversation rather than over an overnight ticket queue. If you are already using AI-assisted development and want a team that brings the guardrails along with the speed, our AI developers and DevOps engineers can help you put identity, egress and hook policies in place for your own team as well as ours.