loading
loading
PixelLeak explained: How coding agents leaked 13,000 screenshots AI coding agents put internal screenshots from more than 300 organizations on public GitHub. No model broke. The agents used permissions nobody meant to give them, to finish a task nobody thought was risky. On September 29, Glow Labs published research it calls PixelLeak. AI coding agents had published more than 13,000 internal images to public GitHub, from developers at more than 300 organizations. The images included customer billing records, a treasury and settlement console at a financial services firm, and screens of features weeks or months from release. Nobody attacked anyone. There was no prompt injection and no malicious package in the main story. A developer asked an agent to show that a UI change worked, and the agent found a way to do it. That way happened to be public. That makes PixelLeak more useful than most incident write-ups. It isn't about a bug you can patch. It's about what happens when an agent holds a person's full set of permissions and nothing separates "finish the task" from "publish this to the internet." PixelLeak by the numbers What happened, step by step Each case Glow investigated started the same way: a developer asked an agent to verify a visual change. The agent took a screenshot so a reviewer could see the result. Then it hit a wall. GitHub's image hosting for pull requests is built into the web interface, and coding agents work from the command line. The agent couldn't attach the image to a private pull request. So the agent solved the problem another way. Glow reproduced the behavior in a lab with Claude Code running Opus 5, and the agent explained its reasoning plainly: "internal_sweeper is private, and GitHub cannot render images from a private repo in a PR description... I created a new public repo, sweeper-demo/pr-assets, holding the two screenshots pinned to a commit SHA." About a third of affected organizations had developers running gitshot, a small open-source tool that publishes screenshots for code reviews. Its images land under a tag that, in Glow's words, is "downloadable by anyone that knows where to look." At one payments company, four employees each had their own gitshot repository. How one workaround became a habit The most telling case is a software vendor. In early July, its agents started publishing code review screenshots publicly. Within a week, more than a dozen agents serving multiple engineers had saved the approach as a skill for every development ticket. Glow counted more than a thousand screenshots and screen recordings from that vendor alone. That's the part worth sitting with. One agent's workaround became shared practice, copied from agent to agent, faster than any human reviewer would notice. Agents that share skills and instruction files also share their mistakes. Why nobody stopped it The agent's reasoning wasn't wrong. It was asked to make an image visible to a reviewer, and it did. What went wrong was everything around the agent: Three things made this possible. The agent acted with the developer's identity, so it could do anything the developer could do. Creating something public was the same kind of action as any other write, with no separate permission or approval. And agent configuration lived with each developer, often on personal accounts the company never saw. In 93% of cases, the images sat in a repository created under an employee's personal username. Glow's own recommendation makes the same point: hardening AI tool configurations is key, and that configuration belongs with the security team rather than with each developer. What to change if your team uses coding agents Glow's write-up lists concrete steps. The short version: - Look beyond your company's GitHub organization. Most cases involved personal accounts, including those of people who have left. - Check releases and gists, not just repository files. Text-based secret scanners don't read images. - Remove any images you find everywhere they appear, and rotate credentials visible in them. - Avoid blanket auto-approval, so agents show you what they're about to do. - Review the shared skill and instruction files your agents load. - Hold or block actions like creating public repositories, pushing to personal accounts or gists, and switching a repository from private to public. Note that Glow sells runtime controls for coding agents, so its recommendations lean toward that approach. The underlying advice holds regardless of the tool you use. If agents use your product, you're GitHub in this story Most B2B products will soon be called by agents acting for their users, through an API or an MCP server. PixelLeak shows what happens when your permission model can't tell an agent from the person behind it. Four design choices help: 1. Give agents their own credentials An agent shouldn't hold the user's session or a copy of their API key. It should present its own credential that names both the agent and the user who delegated to it, so your API can decide what the agent may do separately from what the user may do. 2. Make "make it public" its own permission Sharing externally, changing visibility and publishing are different from ordinary writes. Give them their own permissions, keep them out of the default set for agents, and default new resources to private. 3. Require a person for actions that can't be undone Some actions should pause for a human: anything that exposes data publicly, deletes it or moves it outside the organization. The agent can propose the action. A person approves it. 4. Let the customer's admin set the policy PixelLeak spread because policy lived with each developer. Your enterprise customers need a place where their admin decides what agents can do across the whole organization, and logs showing what agents actually did. Here's what an agent's access token can look like when the agent has its own identity. The scope list includes reading and commenting, but no permission to publish or change visibility: Here sub is the agent's registration ID, act names the user who delegated to it and scope lists what the agent was granted. The scope names are examples. The point is what's missing: an agent with this token can't create a public resource, however good its reasoning. Take the public shortcut off the table AuthKit's Agent Registration gives each agent its own registration ID and short-lived, scoped credentials. Its tokens carry the agent ID in sub, the delegating user in act and granted permissions in scope. Agents can start with limited scopes and get the full set you configure only after a user claims them, through a flow that works like the OAuth device flow. Agent Registration has to be enabled for your environment, so check with your WorkOS account team. WorkOS RBAC lets you define publishing and sharing as separate permissions and keep them out of the roles agents get. Audit Logs records what each agent did and for whom, and streams it to your customer's SIEM. For more on that, see Audit logs for AI agents: Lessons from Claude's Compliance API. PixelLeak won't be the last incident like this. Agents will keep finding the shortest path to the goal you give them. The fix isn't a smarter agent. It's a permission model where the shortest path can't run through the public internet.
document fetched 2026-10-24 10:07