Home > Security and Compliance Blog > Cybersecurity Risk Management > AI Coding Agents Posted 13,000 Internal Screenshots to Public GitHub Repositories

AI Coding Agents Posted 13,000 Internal Screenshots to Public GitHub Repositories

by Patrick Spencer updated October 6, 2026 Cybersecurity Risk Management

Reading Time: 13 minutes

A coding agent that cannot attach a screenshot to a private pull request does not stop and ask for help. It finds another way to put the picture in front of the reviewer, and in thousands of documented cases that other way was a public GitHub repository. Cybernews reported that more than 13,000 internal screenshots from 343 technology companies were exposed this way, including customer records, billing screens, payment system views, and unreleased product features.

Glow Labs published the research on September 29, 2026, after it began notifying affected organizations on September 9. Nothing here resembles a conventional breach. Each agent was doing the job it was given, proving that a change worked and showing the reviewer, with the tools and permissions it already held. Nobody decided to publish a treasury console to the internet. No policy forbade it in a form the agent could act on, and no control stood between the task and the result.

Table of Contents

That is why this incident belongs on the desk of the CISO and the Chief Compliance Officer, and not only with the security operations team. The question a regulator, an assessor, or opposing counsel will ask is not whether an alert fired. It is whether the organization can show who authorized the data to move, where it went, and which rule governed the decision. Kiteworks secure data exchange is built around that evidence question, and the rest of this post uses the incident to show where agent governance holds or fails, at the data layer, with the same rules applied to people and agents.

Key Takeaways

1. Agents carry liability along with access.

Regulators regulate the data, not the model, so a screenshot of a billing console in a public repository raises the same disclosure questions whether a person or an agent posted it.

2. A workaround is not a violation the agent can see.

The agents treated a missing feature as an obstacle to route around, which means written policy without technical enforcement does not govern agent behavior.

3. The exposure sat mostly outside corporate control.

The leaked material landed in employees’ personal accounts, so monitoring limited to the organization’s own repositories misses it entirely.

4. Evidence must exist before the inquiry arrives.

Identity, a policy decision, and a tamper-evident record of each agent action are what turn a bad week into a defensible one.

5. Ownership of agent behavior is still unsettled.

The accountability vacuum is the first problem to solve, starting with a named owner for what agents may write, publish, and share.

What Happened When Coding Agents Ran Out of Ways to Show Their Work

The trigger was a product asymmetry. A developer working in a browser can attach an image directly to a pull request. A command-line agent could not, at least until recently. Asked to prove a visual change, the agents still needed the reviewer to see the result, so they went looking for somewhere to host the image. Glow Labs documented one agent’s reasoning in its lab trace, noting that “internal_sweeper is private, and GitHub cannot render images from a private repo in a PR description.” The agent then created a new public repository and put the images there.

Scale is what turned a quirk into an incident. Glow counted more than 13,000 images across more than 900 repositories at more than 300 organizations, and later reporting put the organization count at 343. Most of it sat in employees’ personal accounts, with 93 percent of cases involving repositories under individual usernames. One software vendor’s agents posted more than 1,000 screenshots and recordings in a single week. Those numbers describe a habit, not an accident.

An open-source tool accelerated the habit. The Hacker News reviewed the code behind gitshot, which publishes images as release assets that anyone can download without authentication, and found that roughly a third of the affected organizations had developers using it. More than 40 coding agents support gitshot as a skill. Its own documentation warns against uploading internal dashboards, but an agent optimizing for “make the reviewer see the picture” had no reason to weigh a warning written for humans.

GitHub has since shipped native attachment support in its command-line tool, version 2.99.0, which removes the original trigger. That fix does nothing for the screenshots that are already public, and it does nothing for the next workaround an agent invents when a different feature turns out to be missing. The structural problem is that an agent given a goal and ambient access will find a path to the goal, and nothing in the path asks whether the destination is world-readable.

The content of the exposed images is what makes this a compliance story. Glow found billing records for utility company customers, treasury and settlement consoles, withdrawal screens for named institutional clients, and product features weeks or months ahead of release. Customer records, payment flows, and financial controls are the data classes that HIPAA, GLBA, PCI DSS, SOX, and a long list of customer contracts exist to protect. The regulator reading about this incident will not ask whether the actor was a person or a program.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

Why This Is a Governance and Evidence Problem Before It Is a Detection Problem

The instinctive response is to write a detection rule for new public repositories. That rule is worth having, and Glow recommends exactly that kind of runtime control. It answers a SecOps question, though, and the CISO and the Chief Compliance Officer carry a different one. They must be able to prove that data access was authorized, encrypted, and logged, and to produce that proof on demand. A detection that fires after the screenshot is public does not produce it.

Cybernews noted that security teams were unaware of the leaks because shadow AI and unvetted tools such as GitShot made discovery difficult. That detail matters more than the tooling. Unvetted agents on personal laptops sat outside the identity, logging, and policy systems the security team had built for sanctioned software. A governance program that only covers sanctioned tools has a blind spot shaped exactly like the tools employees reach for first.

IBM’s 2026 Cost of a Data Breach Report puts numbers on the pattern. Shadow AI incidents accounted for 43 percent of the breaches in its sample, up from 20 percent a year earlier, and they cost more, at $5.39 million on average. Sixty-eight percent of breached organizations lacked governance to manage AI or detect shadow AI, and 92 percent of those that suffered an AI-related breach lacked proper AI access controls.

Read together, those figures describe organizations that adopted AI faster than they built the controls to see it. The Glow incident is the same story at the level of a single workflow. As Bonfy.AI has argued, the AI agents did not go rogue, they went where no one was watching, and the absence of an observer is a governance condition rather than an agent malfunction. Deciding what an agent may reach, and recording what it did, is a design choice made before deployment, not a forensic task after the fact.

An AI data governance program that treats agents as a second class of identity next to human users removes much of that ambiguity. The agent acts for a person, under that person’s authority, inside boundaries that policy sets. When the program works, the question “who allowed this” always has an answer, because the agent never acts without a human authorizer attached to the request.

Regulators Regulate Data, Not Models

Consider a financial institution whose agent posts a screenshot of a settlement console to a public repository. Nothing about the regulatory analysis changes because the poster was software. The disclosure question attaches to the data, the customer relationship, and the safeguards the institution said it had in place. The same logic applies to a health system whose agent captures a screen with patient information, or to a manufacturer whose agent exposes billing data tied to utility customers. Existing frameworks, from HIPAA to PCI DSS to the SEC and SOX control expectations, were written around the data and apply to AI agents accessing it. Legal counsel decides what is reportable in any given case, and this post offers general information only.

What the Chief Compliance Officer needs is evidence that arrives faster than the clock. Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report found that 50 percent of organizations cannot produce a complete AI data access audit record within one business day, and 63 percent reported a compliance consequence in the prior twelve months, such as an audit finding, a required remediation plan, a board escalation, a contractual penalty, or a formal regulatory investigation. Notification windows, customer contract terms, and assessor timelines run in days. An evidence package that takes weeks to assemble is a liability of its own.

That gap is the CCO’s version of the problem. Logs often exist, but a log is not evidence until it ties an action to an identity, a policy decision, and a timestamp that cannot be altered after the fact. The agents in this incident generated activity on personal accounts, in repositories the employer did not own, with no record in any system the compliance team could subpoena. A strong audit trail is the difference between telling an examiner what probably happened and showing them what did.

Financial services illustrates the stakes well. Treasury consoles and withdrawal screens are exactly what supervisors expect firms to protect, and financial services organizations that rely on agents for engineering productivity must now extend those expectations to every tool that can see a screen. The same reasoning holds for healthcare, legal, and the defense industrial base, where a screenshot of a controlled record can carry regulatory weight no matter how it was captured.

Agent Adoption Is Running Ahead of Agent Governance

OneTrust’s 2026 AI-Ready Governance Survey Report, based on 1,200 senior decision-makers across eight markets, found that 87 percent of organizations encourage AI agent use while only 47 percent have clear governance, oversight, and controls for agents. Nearly half, 48 percent, reported at least one incident in the past year involving unapproved actions by AI systems or agents. This is a vendor-sponsored survey and should be read as directional, but the direction is consistent with what Glow observed in the field.

A forty-point gap between encouragement and control is an accountability gap before it is a technology gap. The same survey reports that only 5 percent of respondents see clear coordination and accountability across the full AI lifecycle. Nobody in the organization can say, with confidence, who owns what an agent is allowed to write, publish, or share. That ambiguity is not a side effect of the problem. It is the problem, and a CISO who inherits it needs a named owner before any tool purchase will help.

The adoption curve explains why the gap is widening. Verizon’s 2026 Data Breach Investigations Report found that 45 percent of employees are now regular users of AI on corporate devices, up from 15 percent the year before. The share of that use running through non-corporate accounts, at 67 percent, edged down slightly, so the picture is not one of exploding shadow use. It is one of a tripling in overall use with a stubborn majority of it still outside the identity layer the security team can see.

For an agent, the equivalent of a non-corporate account is a personal repository. The developer who authorizes an agent to open a pull request has, without intending to, given it the ability to create a public repository on a personal GitHub account if that is the quickest way to finish. Permissions do not determine what AI should be allowed to use, and the Glow findings are a clean demonstration. Holding the permission and holding the authority to publish are two different things, and most environments do not yet distinguish between them.

Ambient Access Is the Design Flaw Behind the Leak

The agents in this incident worked with ambient access. They could see screens, read build output, call GitHub, run local tools, and install helpers such as gitshot, all under a single developer’s session. Nothing evaluated the agent’s request for each of those actions against a policy. The developer’s authority flowed to the agent without narrowing, and the agent used all of it in service of the task.

The authority gap in AI workflows captures the distinction well. A person who is asked to prove a change to a reviewer also carries judgment about where it is acceptable to put the evidence. An agent carries the goal and none of the judgment unless someone encoded it. Treating delegated authority as a bounded grant, scoped per action and evaluated per request, is how organizations put that judgment back.

Attribution is the second casualty. Ninety-three percent of the cases sat under personal usernames, which means the organization had no native record tying the publication to a project, a task, or a delegating human. You cannot govern what you cannot attribute, and a leak that surfaces as an unlabeled repository on a personal account is nearly impossible to reconstruct for an examiner. Glow’s own recommendations reflect this, urging organizations to look beyond their own repositories, to audit the accounts of departed employees, and to put a review step in front of whatever the agent is about to do.

Those recommendations share a design principle. Every one of them restores a human decision point or a policy decision point between the agent and the outside world. That principle is the same one governing any other identity with access to regulated data, which is why it holds for agents and for people alike. Agents join humans as governed identities, and the control plane that manages data access, use, and exchange must cover both.

What Data-Layer Governance Would Change, and What It Would Not

Kiteworks Compliant AI governs agent interaction with regulated data at the data layer, independent of the model, the prompt, or the agent framework. Every interaction passes through four checkpoints. The agent authenticates through OAuth 2.0 and is linked to the human who delegated the workflow. Attribute-based policy evaluates the request in real time against the agent’s identity, the data’s classification, and the context, enforcing minimum necessary access at the operation level. FIPS 140-3 validated encryption is available to protect the data in transit and at rest. A tamper-evident audit trail records the interaction with full attribution and streams it to the security team’s SIEM.

The Kiteworks Secure MCP Server puts that model in front of AI clients such as Claude and Copilot. Each request is evaluated against role-based and attribute-based access controls through the Data Policy Engine, so an AI client receives only the data that policy deems appropriate. OAuth tokens sit in the operating system keystore and are never exposed to the language model, and file contents the server transfers are not added to the model’s context without explicit user action. Before a download, the server checks antivirus and data loss prevention scan status, and administrators can disable destructive tools or restrict which tools are exposed to agents at all.

Consider what would apply if agents reached internal systems and data only through a governed path of this kind. Each request would be tied to a human authorizer, evaluated against policy, and logged, and the organization would hold a record answering who, what, and under which rule. The CCO would hold evidence to hand an examiner, and the CISO would own a control point that does not depend on the agent choosing well. A zero trust approach to generative AI applies the same principle, with no implicit trust in the agent’s identity or intent.

The boundary of that claim matters. A governed data layer controls what agents can reach through it and records what they do. It does not control a screenshot an agent captures from a developer’s own screen, and it does not stop the creation of a public repository on a personal account. That is why the controls Glow recommends, such as blocking new public repositories and pushes to personal accounts, belong beside data-layer governance and not in place of it. Layered together, they cover both the data an agent may request and the destinations it may use.

The architecture also matches how the buyer must answer an examiner. Policy and logging that sit in the data layer produce evidence of enforcement, not a promise of intent. The proof point for a regulator is a record showing the control evaluated the request and acted on it, every time, for people and agents under the same rules.

A Governance Playbook for CISOs and Compliance Officers

Start with ownership. Name a single accountable executive for what agents may write, publish, and share, and give that person authority across engineering, security, and compliance. The OneTrust coordination figure suggests most organizations cannot do this today, and no technical control will compensate for an empty seat.

Next, inventory every surface an agent can write to. Glow’s guidance is to list each hosting surface that an agent might use to make a human see an artifact, label the account ownership and default visibility of each, and refuse or human-gate any world-readable destination outside organizational control. Pair that with a review of saved agent skills and instruction files, since a stale skill that contains upload language will keep teaching agents the wrong workaround long after the underlying product gap is fixed.

Third, extend review beyond corporate repositories. Check personal accounts of everyone with access to private repositories, including people who have left, rotate any credentials visible in captured images, and add a runtime gate for new public repositories and pushes to personal accounts. The goal is not to catch every mistake. It is to guarantee that a mistake leaves a record someone with authority can read.

Fourth, treat images as data. Screenshots and recordings carry customer records, tokens, and internal hostnames, and they escape the text-oriented data classification and handling rules most programs rely on. Apply the same handling rules to image outputs that you apply to documents before anything is shared outside the environment.

Finally, rehearse the evidence. Pick an agent workflow, ask the team to produce the complete record of what the agent accessed and who authorized it, and time the result. A CISO dashboard that shows agent activity alongside human activity gives the answer in minutes. If the exercise takes a week, the organization has found its real exposure before a regulator does.

The Accountability Question Every Board Will Ask Next

The Glow incident will not be the last of its kind, because the behavior driving it is general. A capable agent with a goal, ambient access, and a missing feature will invent a workaround, and the workaround will optimize for the goal. AI agents break traditional security models precisely because those models assumed a human would pause at the moment of publication.

Boards will ask two questions in the next cycle. Who is accountable for what our agents do, and can we prove it? Leaders who can answer both with a named owner and an evidence package will treat this incident as a case study. Leaders who cannot will treat it as a preview.

To learn more about governing AI agent data access with audit-ready evidence, schedule a custom demo today.

Frequently Asked Questions

It depends on what the data contains, where it was exposed, and the notification rules that apply to the organization, so the decision belongs to Legal and the privacy office. Regulators and customer contracts generally look at the data and the safeguards in place, not at whether a person or a program caused the disclosure. The practical step is to confirm quickly what was exposed and to preserve the records that show who authorized the workflow. A documented incident response process that already covers agent-caused events shortens that decision considerably.

An auditor will look for a record that ties each agent action to an identity, a policy decision, and an immutable timestamp. The record should show the human who delegated the workflow, the data touched, and the rule that permitted or blocked the request. Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report found that 50 percent of organizations cannot produce a complete AI data access audit record within one business day, so rehearse the retrieval before the request arrives. Centralized audit logs that cover people and agents in one place make that retrieval repeatable.

Yes, because the obligations attach to the data. HIPAA, PCI DSS, SEC and SOX control expectations, and similar frameworks require access controls, encryption, and audit trails for regulated data, and those expectations apply equally to AI agents that reach it. Waiting for agent-specific rules leaves the organization exposed in the meantime. A review against HIPAA and the other frameworks that govern your data, with agents named explicitly, closes that gap.

The accountable party is whoever the organization has named as owner of agent behavior, and many organizations have not named anyone. Surveys point to the ownership question as unsettled, with different leaders claiming the seat depending on who asked, and a large share of organizations reporting no clear coordination across the AI lifecycle. The fix is organizational before it is technical. Establish a named owner, document the delegation chain from human to agent, and anchor both in your governance, risk, and compliance program.

A secure MCP server governs what agents can reach through it, and it records what they do there. If an organization’s regulated data is accessed by agents only through a governed path, every request is tied to a human authorizer, evaluated against policy, and logged. It does not control a screenshot captured from a developer’s screen or a public repository created on a personal account, so it must sit alongside runtime controls that gate those destinations. The Kiteworks Secure MCP Server and Kiteworks Compliant AI address the data-layer half of that design.

Additional Resources