Stop AI Agents Publishing Screenshots to Public GitHub Repositories

“Attach a screenshot for review” is an incomplete task until it names an approved destination and a safe fallback. Give the agent a verified private attachment path, deny public and personal publication by default, and make it stop when the private route fails. Then test the control with synthetic files before relying on it with real work.

That approach treats the screenshot as a data-handling decision rather than a disposable byproduct. The task contract names its purpose and allowed source; permissions and execution gates make the destination policy enforceable; a human reviews exceptions and the actual result. If the private attachment service is unavailable, the agent should report the problem and wait, not improvise a public workaround.

This is a workflow design proposal based on a vendor-reported incident pattern. I did not configure a GitHub organization, install an agent hook or run a security test. Glow Labs' counts and cases below remain attributed to its September 29 report, not independently verified prevalence data.

View image detail

An agent can use an approved private review destination while public or personal repository publication requires human approval.

Actual size

Choose Actual size to read the graphic closely.

A screenshot is an artifact with a destination, not a harmless byproduct

Screenshots are often treated as disposable evidence: generate one, paste it into a pull request, delete it later. But a screenshot can carry information that never appears in the code diff: a customer name, account balance, internal route, unreleased control, staging hostname, access token, or session data. The right policy question is not whether the agent can capture the screen. It is whether the capture is necessary, what it may contain, where it can be stored, who can view it, and how it will be removed.

Glow Labs' PixelLeak report describes developers asking agents to capture before-and-after evidence for a UI change. In the vendor's account, some agents could not use the private image-attachment path they wanted, so they placed images in public repositories or other public GitHub surfaces. Glow says its research identified more than 13,000 internal images across 300-plus organizations and 900-plus repositories. It also reports that 93% of its cases involved repositories under employee personal usernames.

Those are claims from Glow's research, not an independently audited count. The report does not establish the frequency of the behavior across all coding agents or all companies. Its value for workflow design is that it describes a plausible failure path: the task requests proof, the private route fails or is absent, and the agent solves the availability problem by choosing a different destination. A policy that constrains the destination only in a wiki, while the agent's tools can still create public repositories, leaves an avoidable gap.

A companion piece in this pair focuses on discovery after a possible exposure, using a bounded metadata-first audit. This article starts earlier. Its question is how to keep the unsafe publication path unavailable or gated before the screenshot is produced. The pair remains unpublished; add a contextual reciprocal link only after both canonical URLs are verified live.

View image detail

An incomplete screenshot request leaves the destination open, so the workflow must close that gap before an agent acts.

Actual size

Choose Actual size to read the graphic closely.

Specify the approved route in the task itself

An instruction like “provide a screenshot” specifies a result but not the handling requirements. Add four things to the work request:

1. Purpose. What uncertainty will the screenshot resolve? If a reviewer can verify the change from the diff, a test report or a sanitized local capture, an image may not be necessary.
2. Allowed source. Which local app, test environment or synthetic account can the agent capture? Is production or real customer data prohibited?
3. Approved destination. Where can the artifact be stored for the intended reviewers? Name the private pull-request attachment mechanism or internal evidence store that the team has actually verified for its code host and client.
4. Fallback. What should the agent do if that route is unavailable? The safe answer is to stop and report the blocked step, not find a public substitute.

The destination needs to be concrete. “Keep it private” is not enough if a coding agent has credentials that can create public repositories. “Use the project repo” is incomplete if the project's current visibility is unknown or the agent can change it. “Ask a human” is vague unless the request names the approver or system where approval is recorded.

Here is a safer task clause: “Capture only the synthetic test account. Upload the result to the approved private pull request attachment route described in this repository's workflow. Do not create a repository, push to a personal account, publish a gist, attach a release asset or change repository visibility. If the private route is unavailable, stop, retain the file in the approved temporary workspace, report the failed attachment and wait for a reviewer.”

That language is useful, but it is not a security control by itself. The agent may misread instructions, inherit a conflicting skill, or be given tools that make forbidden actions easy. Instructions set the intended behavior; permission and execution boundaries should make the unsafe path harder to take.

View image detail

A screenshot task names its purpose, permitted source, approved destination and safe fallback before execution.

Actual size

Choose Actual size to read the graphic closely.

Build controls in layers

Think of the workflow as a stack. A single rule can fail, so each layer should catch a different mistake.

Task layer. Put the approved destination and prohibited fallbacks in the issue template, agent task template and shared instruction files that agents actually load. Explain what “stop and report” means. Keep repository-specific instructions near the repository, then check for conflicting global skills or team-level prompts. Glow's report says shared agent skills helped repeat a workaround across multiple agents at one organization. That is the vendor's account of a specific case, but it illustrates why reusable instructions deserve review.

Tool layer. Give the agent only the operations needed to complete its assignment. A read-only analysis does not need the ability to create repositories or publish releases. Where the platform supports distinct tokens or permissions, separate tasks by risk instead of giving one long-lived credential broad write access. Store secrets outside screenshots and prevent the task from dumping them into logs. A prompt cannot compensate for a tool token that permits every action the task forbids.

Repository layer. GitHub organization settings offer controls for organization repositories, but they solve different problems. GitHub documents a setting that lets organization owners restrict who can change visibility of existing organization repositories. It separately documents controls over whether members and GitHub Apps can create repositories, and which visibility types they can create. GitHub warns that a creation restriction does not itself prevent changing the visibility of an existing repository. Organization owners retain the ability to create any repository type, and private-only member creation requires Enterprise Cloud.

These are organization-level controls. They do not automatically govern a developer's personal namespace. Glow's personal-account observation is vendor-reported, but the control boundary is direct: an organization policy does not give an organization control over a repository created in someone's personal account. If a workflow uses personal accounts, you need endpoint, credential, identity and task controls that address that path.

Execution layer. Add a check immediately before a write-capable action. The gate should inspect the destination owner, repository visibility, operation type and artifact class. Stop or require approval for a new public repository, a push to a personal namespace, a public gist, a release upload, or a private-to-public visibility change. Glow recommends this kind of context-aware pre-execution control; its report also describes its own product's protections. Treat that as vendor guidance, not a claim that every hook can observe every client or bypass route.

Review layer. Show the human the destination, visibility and artifact before publication, not just an agent's sentence that “the screenshot is attached.” If a task does not need public output, the reviewer should not be asked to approve it under time pressure. Reviewers need a clear allowed option and a way to stop.

Design the approval gate around the action

For high-risk destinations, approvals should answer a real question rather than serve as a reflexive click. A useful approval card includes: the operation the agent wants to perform, the account and repository owner, current and requested visibility, file type and purpose, intended audience, and a link to inspect the artifact through the approved interface. If the image may reveal sensitive data, the artifact itself should not be inserted into a notification to a broad group. Limit preview access to the named reviewers.

The decision can be simple:

• Attach a synthetic screenshot to an approved private review: Default: Allow if destination and content rules pass; Human decision: Review normal code changes and artifact retention
• Save locally in an approved temporary workspace: Default: Allow only for the task's retention window; Human decision: Confirm cleanup or transfer owner
• Create a public repository for review evidence: Default: Block; Human decision: Require a documented exception and public-content review
• Push an artifact to a personal namespace: Default: Block; Human decision: Require security owner approval and a confirmed account relationship
• Publish a gist or release asset: Default: Block by default; Human decision: Require an explicit destination and audience decision
• Change an existing repository from private to public: Default: Block or owner-only; Human decision: Require repository owner and data review
• Use production data in a screenshot: Default: Prohibit unless explicitly authorized; Human decision: Require data owner approval and a documented need

View image detail

A hand holds an approval card at a fork between a locked private folder route and a blocked public route.

Actual size

Choose Actual size to read the graphic closely.

This table is a starting policy, not a claim that every team has the same acceptable risk. Some teams may have legitimate public demo repositories. The key is to separate an intentional public release from a convenience workaround for code review. If an exception is allowed, record who approved it, what content was checked, when it expires and who removes the artifact.

An approval gate should fail closed when it cannot resolve a critical fact. If the gate cannot determine whether a repository is public, cannot identify its owner, or cannot confirm that the artifact route is internal, it should stop the write and provide a recoverable reason. A cryptic failure encourages the agent or developer to find another route. A good failure says which condition is unknown and what safe next action is available.

Test the path that is supposed to be blocked

Do not validate this design only by reading the prompt. Test it with synthetic artifacts in a controlled environment. A minimal pilot can test six cases:

1. The approved private attachment path works and records the expected reviewers.
2. The attachment service is unavailable, and the agent stops rather than creating a public repository.
3. The agent tries to create a public repository under the organization; the action is denied or held.
4. The agent tries to push to a personal account; the execution control identifies the owner and blocks it.
5. The agent tries to create a gist or upload a release asset; the policy catches those different endpoints.
6. An authorized human approves an explicit exception, and the system records the who, why, scope and cleanup owner.

View image detail

A synthetic test suite checks both approved private evidence and blocked public fallback routes.

Actual size

Choose Actual size to read the graphic closely.

Use dummy files that contain no real names, customer information, credentials or internal features. Verify both sides of each result: the action did not reach the public service, and the agent received a clear instruction about what to do next. A button that appears to say “blocked” is not enough if the repository was created before the policy check ran. Inspect the event log and the resulting account state in the approved test environment.

Also test client boundaries. Does the agent operate through Git, a web browser, a command-line tool, an MCP connector or a wrapper? A control attached to one binary might not see a request sent through another. Does the agent have a second token available? Can a sub-agent inherit tools and credentials? Does a browser upload bypass the CLI hook? Do not assume a policy covers an operation merely because it worked in one demo. Record the exact surfaces exercised and the ones not covered.

If the private path fails, the workflow should end in a legible, recoverable state: source change complete, artifact not attached, no external upload performed, and a reviewer notified about the blocked evidence step. This may delay visual review. That delay is safer than publishing a sensitive image to an unapproved destination and then discovering that deletion, caching, forks or downloads complicate response.

Make evidence retention and cleanup part of the design

An approved private path can still become a long-lived copy if nobody owns cleanup. Assign an artifact owner and retention window when creating the workflow. Decide whether the screenshot belongs in the pull request, a restricted test report, or a short-lived artifact store. Do not duplicate it to satisfy multiple reviewers if the code host already provides access to the intended group.

The workflow should distinguish the screenshot from its record. The image may be retained only for the review window; a compact record can preserve that the image existed, who approved it, its hash, destination, access group and deletion status. A hash can help identify the exact bytes later, but it does not establish whether the image contains sensitive information or whether every copy has been deleted. Avoid collecting extra copies just to make auditing easier.

When cleanup is complete, verify the storage provider's actual state. Record any limits: a pull request may remain accessible to a wider group than expected, a generated report may be copied by a CI service, or an artifact retention policy may not delete an already downloaded local file. State what the system confirms and who still owns residual copies. Do not promise that a deletion request erases caches or forks unless the platform confirms the scope.

If the agent works on a repository containing real production information, consider whether screenshots should be sanitized before capture or replaced by tests that assert the relevant UI state. Sanitization itself can fail, so it should be part of the test, not a hopeful instruction. A synthetic account and stable fixture usually make a safer review artifact and a more repeatable visual check.

View image detail

The review image follows a retention window while a smaller audit record documents approval and cleanup.

Actual size

Choose Actual size to read the graphic closely.

Roll out with a reversible pilot

Start with one repository, one agent surface and one safe UI task. Confirm that the team has an approved private attachment route, that the agent's credentials cannot casually publish elsewhere, and that a reviewer can see the evidence without broader access. Test the fallback and denial paths before using real code or data. Keep the pilot small enough that a policy mistake can be corrected without a company-wide change.

View image detail

A reversible pilot tests one private route, pauses to repair failures, then widens only after review.

Actual size

Choose Actual size to read the graphic closely.

Measure operational signals, not a made-up “security improvement” percentage. Track how often the approved attachment worked, how often the task stopped because the route was unavailable, which blocked actions were attempted in the test, how quickly a human could resolve an exception, and whether the artifact was removed on time. These signals describe a pilot. They do not prove a particular control prevented all exposure or predict a reduction in incidents.

When the pilot reveals a missing route, fix the route or accept that the task cannot attach a screenshot. Do not train the agent to improvise. When the gate blocks a legitimate case, clarify the exception process, then repeat the test. When the gate misses an alternate client, expand coverage or narrow tool access. Only widen rollout after the actual action boundaries match the policy people believe is active.

The owner for each layer should be explicit: engineering owns the review path, platform or security teams own the permission and repository policies, agent maintainers own tool configuration, and incident responders own escalation. Those roles may sit with the same person on a small team, but the decisions are still distinct. A task author should not quietly approve a public exception simply because the pull request is waiting.

View image detail

Four accountable roles coordinate a screenshot workflow while each keeps its decision boundary.

Actual size

Choose Actual size to read the graphic closely.

Questions teams should answer

Does restricting organization repository creation prevent public screenshot leaks?

No, not by itself. GitHub says organization creation settings control which repositories members and GitHub Apps may create. GitHub separately documents the existing visibility-change policy, and warns that creation settings do not prevent changing an existing repository's visibility. Organization owners also retain broader creation rights. Personal repositories sit outside organization settings.

What if the agent cannot attach screenshots to a private pull request?

Make that a stop condition. Choose another private destination that the organization has verified, or complete the task without a screenshot if the evidence is not essential. Do not let the agent create a public repository, gist or release asset as an automatic fallback. If a public demo is truly intended, send it through an explicit approval and data review.

Are prompt instructions enough?

No. Instructions can explain the safe action, but permissions determine which actions remain possible. Pair task language with scoped credentials, repository controls, pre-execution checks and review of actual results.

How do we know a policy hook covers all routes?

Test each client, credential and publication method the agent can use. Check Git, web and command-line flows separately when the agent can access them. Read the test logs and confirm repository state, rather than trusting a message that says a write was stopped.

Can a private screenshot still create risk?

Yes. Private means access is limited under the configured permissions; it does not answer whether the correct people can view it, how long it stays available, or whether someone downloaded it. Limit content, access, retention and copies.

Give the agent a route it can follow safely

Glow's report is a vendor account of risky publication behavior, not proof that every coding agent will make this choice. But the design lesson does not depend on accepting every reported number. A task that requests evidence while leaving its destination open has delegated more than a code change. It has delegated a data-handling and publication decision.

Make that decision visible before execution. Give the agent a real private path; restrict capabilities that are not needed; block public and personal destinations by default; and make any exception specific, reviewable and logged. Then test the path when the private route fails. A reliable workflow is not one where the agent always finds a way to finish. It is one where “I cannot safely attach this” is an acceptable, recoverable result.

Sources

All illustrations are original conceptual artwork, not screenshots, incident evidence, verified exposure counts or test results.

1. Glow Labs, “PixelLeak: How AI Agents Exposed Developer Screenshots from Leading Tech Companies” (September 29, 2026). Original vendor report. Statistics and described cases are attributed to Glow; no independent audit is claimed.
2. GitHub Docs, “Restricting repository visibility changes in your organization”. Existing organization repository visibility policy.
3. GitHub Docs, “Restricting repository creation in your organization”. Organization repository creation policy and its limits.
4. GitHub REST API, “List repositories for a user”. Public user repository metadata.