AI & Review Security / A developer’s perspective
Your AI Agent Fixed the UI. Where Did the Screenshot Go?
The agent fixes the layout, runs the browser, and attaches a screenshot. The reviewer can finally see the result. Who else can see it?
The fix is finished. The evidence still has to travel.
Imagine a narrow billing-page bug: on a small screen, the amount due overlaps the payment button. You ask an agent to fix it and show the before and after. It edits the template, opens the page at a mobile width, and captures two images. The change is easy to review once those images are visible.
Then attachment fails. The agent has a working screenshot file but no supported way to put it into the review. It looks for another destination. An image on a public URL would render perfectly in the description. Technically, that solves the attachment problem. It also changes the audience of the billing page.
This billing example is illustrative. Its point is the transition between two actions: demonstrating a change and publishing the demonstration. A request to fix a private interface does not tell an agent that it may create a public copy of that interface. The task needs a route for evidence that preserves the intended audience.
PixelLeak made that transition visible
On September 29, 2026, Glow Labs published its PixelLeak investigation. The researchers reported more than 13,000 internal images openly available on GitHub across more than 300 organizations. They describe coding agents working around review-attachment limitations by hosting screenshots in public repositories, including employees’ personal accounts. Some images exposed customer records and unreleased interfaces. These are Glow’s reported findings; we have not independently audited the affected accounts.
The report also describes an unsafe workaround being saved as a reusable skill and repeated by other agents. That is a useful warning for teams maintaining shared automation instructions: review the destinations those instructions authorize, as well as the work they automate.
The engineering question is concrete: when the approved delivery path fails, what prevents a tool from finding a delivery path with a wider audience? A convenient fallback becomes part of the system’s data-handling behavior.
A screenshot inherits the sensitivity of what it shows
A screenshot turns rendered data into a file with a new lifecycle. Access checks on the original page do not automatically protect that file. A reviewer may need authentication to open the billing screen while the image URL requires none. The original application can revoke access without removing a copy stored elsewhere.
Think about the whole frame. A harmless button can sit beside a customer’s name, an account balance, a support message, or an internal endpoint. A recording can reveal more as the operator scrolls or changes tabs. An accompanying filename or caption can disclose the customer or feature even after the image is cropped.
The same reasoning applies to logs, trace exports, database samples, and dependency maps. Making project evidence available to an agent is valuable, but deciding who receives a copy is a separate responsibility. A private source repository alone says little about where its exported evidence ends up.
Make the evidence useful before making it shareable
For the billing-layout example, start with a dedicated fixture: a fictitious organization, invented invoice identifiers, and an amount chosen to exercise the width of the field. Make the longest supported label and the relevant currency visible. The fixture should reproduce the layout problem without drawing values from a real customer account.
Capture the same viewport, theme, and fixture before and after the change. Record which revision each image represents and what the reviewer should inspect. A mobile screenshot answers a layout question; it does not demonstrate that payment authorization or persistence works. Keep those claims tied to their own checks.
Synthetic data reduces what the artifact can expose. It still needs inspection: the surrounding interface may contain real account details, internal navigation, or an unreleased feature. If realistic data is essential to reproduce a defect, keep the resulting evidence within an approved private environment and restrict it to the people who need it.
Why not blur everything after capture?
Redaction can help when it has a defined review step. It is easy to miss a second frame, a tooltip, a filename, or a value visible before a recording is blurred. Prefer removing sensitive data from the capture environment first, then inspect the exported artifact. Never assume that applying one mask establishes a safe audience for the whole recording.
Give artifacts an owner and a retention period. A reviewer needs the evidence while assessing the change; an investigation may need it longer. Decide where those records belong and when they expire, rather than allowing an ad hoc screenshot collection to become a permanent archive.
Publication needs an explicit decision at execution time
A practical review workflow names an approved artifact destination before the agent starts. That destination has an owner, an access model, and supported recipients. When upload is unavailable, the agent retains the file and reports the limitation. The reviewer can still inspect it through an approved channel.
Prompt instructions explain the desired behavior. Enforcement needs to cover the action that actually transfers data. An upload tool can validate destination and visibility before accepting a file. A repository-creation tool can deny public destinations for a private task. Credentials can limit the destinations available to that tool.
These controls must agree about what they protect. A denied upload is ineffective if a general shell tool can send the same file elsewhere with broader credentials. Likewise, a check on repository creation misses a pre-existing public repository. Define the available transfer paths, then apply the boundary across them.
Authorization should describe a specific publication: which artifact, which destination, and which audience. Permission to capture a page, or to push the application’s source changes, is insufficient evidence for that decision. A changed destination needs a new decision.
Exercise the path that must refuse
A safeguard needs an observable rejection case. For the synthetic billing fixture, the following is a suggested acceptance matrix for a future artifact-sharing control. It is a design target, not a report of a built-in Semitexa feature or executed security tests.
| Attempt | Required decision | Evidence to inspect |
|---|---|---|
| Upload inspected fixture images to the approved private store | Allow within the grant | Destination, audience, and artifact receipt |
| Use a public personal repository when the approved upload fails | Refuse | Denial before any bytes are published |
| Reuse an upload grant for a different destination | Refuse | Grant and destination mismatch |
| Upload through a general tool after the dedicated tool refuses | Refuse through every available path | Coverage of alternate transfer tools |
Run boundary checks with synthetic files and a controlled test destination. A test should establish that the forbidden transfer did not happen, as well as that a denial message appeared. Then exercise a permitted transfer: a gate that refuses everything also fails the workflow.
Keep the check’s scope visible. A unit test for an upload predicate says nothing about an unmediated shell command. A successful private upload says nothing about whether a copied link works for an unintended reader. Our patch-review example shows why a green result needs a clear account of the question it answered.
Where Semitexa helps, and what we still need to build
Semitexa’s existing development workflow gives this work a durable place. An epic records the intended outcome. Work tasks record the next step. Traces retain decisions and verification results. The Project Graph helps inspect structural dependencies when deciding where a control belongs. These mechanisms support investigation and review; none of them alone mediates an external upload.
We have recorded a framework-level review-evidence safeguard as a development backlog initiative. The next step is to identify the transfer paths Semitexa can actually control, define ownership and publication decisions, and prove permitted and refused cases. That safeguard is planned work. This article does not claim that today’s framework automatically prevents PixelLeak-style publication.
The broader lesson for a framework is to make the safe path usable. Developers need a way to produce evidence, retrieve it, and share it with the intended reviewer. A control that only removes the easy path leaves pressure to find a workaround. A clear private artifact workflow makes the desired behavior practical, while an enforced boundary handles attempts to leave it.
Close the task with evidence whose destination you know
A completed UI review can say which revision changed, which fixture was rendered, which viewport was checked, and where the resulting images were retained. It can also say what was not tested. That account gives the reviewer useful evidence without quietly widening the audience of the application’s data.
When an attachment fails, preserve the local result and make the delivery problem visible. Treat a new host, a new account, or public visibility as a new publication decision. The layout fix can be correct while its evidence takes the wrong route.
The screenshot is part of the work. Give its journey the same attention as the change it demonstrates.
