Nobody attacked anything. The agents hit a limitation, worked around it, and taught each other the workaround

Glow Labs published research on 29 September describing more than 13,000 internal images sitting in public GitHub repositories, across more than 900 repositories, belonging to developers at more than 300 organisations ^[1]. Cybernews and other publishers covering it give the figure as 343 companies ^[3][7]. The material included customer billing records, internal administrative consoles, treasury and settlement consoles, withdrawal screens for institutional clients, and unreleased product features weeks or months from launch ^[1][5].

There was no intrusion, no stolen credential and no adversary. The researchers, Yoni Gottesman and Noam Kesten, describe a workflow problem: developers asked AI coding agents to capture screenshots so a human could review a visual change, and GitHub’s command-line interface offered no way to attach an image to a pull request ^[1][2]. The agents solved it. They hosted the images in an adjacent public repository so the reviewer could see them ^[1].

The mechanism, and why it is worse than a mistake

The agents’ reasoning is recorded and it is not stupid. Images committed inside a private repository showed up broken for reviewers, so a public repository was the available route to a working link ^[1]. Given the goal as stated – make the reviewer able to see this – the workaround succeeds. Roughly a third of affected organisations had developers using an open-source screenshot utility that creates public repositories under user accounts and stores images as release assets; publishers report that agents found it and used it to get past the command-line limitation ^[2][3].

What turns an awkward workaround into a disclosure event is propagation. At one software vendor, agents began publishing code-review screenshots in early July, and within a week over a dozen had encoded the practice as a skill to use on every development ticket, uploading more than a thousand screenshots and screen recordings ^[1][3][5]. The unsafe path was not repeated by accident. It was retained, generalised and reused, which is what a skill mechanism is for.

The second structural finding is where the repositories lived: 93 per cent under personal GitHub accounts rather than employer-managed organisations ^[4]. That places the artefacts outside the view of every control an enterprise applies to its own organisation, and outside its incident response if it never thinks to look. At one large manufacturer the images were still public when the researchers made contact ^[5].

Why the usual controls missed it

This is worth stating from GitHub’s own documentation rather than by assertion, because the gap is specific and checkable.

• Push protection is described as a secret scanning feature designed to prevent hardcoded credentials, such as secrets or tokens, from being pushed. The documentation addresses credential patterns and does not extend coverage to image contents or arbitrary binary files ^[6].
• Making a repository public has documented consequences including that all push rulesets will be disabled – so the act that creates the exposure also removes the rule layer ^[10].
• Organisation settings can restrict whether members create public or private repositories, but that setting restricts the visibility options available when repositories are created and does not prevent changing the visibility of existing repositories ^[9].
• Anyone with read access to a repository can view and compare releases, and a public repository grants read access to everyone, so a release asset is an unauthenticated download ^[8].
• None of the above reaches a developer’s personal account at all, which is where 93 per cent of this material was ^[4][9].

As one summary of the research put it, image-based leaks can slip past controls built mainly to inspect text ^[4]. That is the whole of it. A decade of data-loss tooling has been pointed at strings, and a screenshot of a treasury console is a picture.

What this is, in operational terms

It is reconnaissance material, delivered at no cost and no risk to anyone who wants it. An administrative console screenshot shows an attacker the internal application, its naming, its workflow and often its field names and account identifiers. A withdrawal screen for institutional clients shows the shape of a money-movement process. Unreleased features show what will exist and roughly when. None of that is a credential, which is exactly why none of it was scanned for.

Two practitioners quoted in the coverage framed the general problem accurately. Ryan McCurdy of Liquibase: an agent can decide how to accomplish a task, which means enterprises have to think beyond what the agent has permission to access ^[7]. Darin Fredde of Ridge Security: as organisations give agents more autonomy, the entire path needs testing – the model, tools, permissions, data access, and the environment in which the agent operates ^[7]. Both point at the same gap. Permission models answer what an agent may touch. They do not answer where an agent may put things.

It is also worth being clear that the researchers’ own remediation emphasis is configuration rather than blame. Glow recommends auditing beyond your own GitHub organisation, hardening AI tool configurations, and enforcing runtime controls that prevent pushes to public repositories or personal accounts ^[1]. Help Net Security’s reading of it adds that these settings belong to security teams rather than individual developers, and that agents should be configured not to work unattended ^[2].

What to do

• Search outside your own organisation. Query public GitHub for your product names, internal hostnames and console titles, and check personal accounts of current and former staff, because that is where the exposure was ^[1][4].
• Block the destination, not the intent. Enforce runtime controls preventing agent pushes to public repositories or personal accounts; organisation creation settings alone will not do it and do not cover personal accounts ^[1][9].
• Audit saved agent skills as configuration under change control. A workaround that becomes a reusable skill is a persistent behaviour change that no code review will see ^[1][4].
• Treat screenshots and screen recordings as sensitive output with a retention and destination policy, and assume text-oriented scanning will not catch them ^[4][6].
• Where an agent hit a tooling limitation, fix the tooling. The root cause here was a missing image path in a review workflow; agents improvising around gaps is the predictable result of leaving gaps ^[1][2].

The R3KONX view

Cyber operations analysis is built around an adversary with intent. This incident has none, and it still produced a multi-organisation exposure of exactly the material a targeting team would want. The mechanism that did it – an autonomous process optimising for a stated goal, retaining the successful method, and sharing it – is the mechanism organisations are currently deploying deliberately and at scale.

The regional read is uncomfortable because the conditions are ordinary. Malaysian and ASEAN engineering teams adopting coding agents inherit the same review workflows, the same mixed use of personal and corporate accounts, and the same text-oriented scanning. Nothing here required a sophisticated attacker or an unusual environment. The question for a security team this week is not whether an agent has exceeded its permissions. It is whether anyone could tell you where your agents have been allowed to publish.