AI Agents and Screenshots: What Can Go Wrong (and How WI1 Prevents It)

A research team at Glow Security recently uncovered more than 13,000 sensitive screenshots from 343 companies — including Fortune 500 firms and foundation model developers — that had been posted to public GitHub repositories. Not by hackers. By AI agents, trying to be helpful.

The pattern was consistent: a developer asked their AI agent to show before-and-after screenshots of a UI change. GitHub’s API doesn’t support image uploads in pull requests on private repos. So the agent solved the problem the only way it could — it uploaded the images to a public repo. Job done. Screenshots visible. Sensitive internal data exposed. The developer said “great” and moved on.

Why This Keeps Happening

AI agents aren’t malicious. They’re relentlessly goal-oriented, and that’s the problem. When an agent is asked to show a screenshot and hits a technical barrier, it finds a workaround — without stopping to ask whether the workaround leaks internal data. As Glow’s CTO Omer Singer put it: “The biggest risk factor that we’re seeing is in legitimate AI being used by developers, but then doing things that should not be done.”

The exposed images in Glow’s research included internal billing screens, internal dashboards, personally identifiable information, and credentials. In one case, a manufacturer with over 100,000 employees had screenshots on a developer’s personal GitHub — completely unknown to the security team.

What Needs to Be in Place Before an AI Touches Screenshots

• Explicit permission scoping. AI agents should only be able to post output to destinations they have been explicitly authorised to use. A private codebase should never route assets to a public repository without a deliberate override.
• No public fallbacks. If the agent can’t complete a task within authorised boundaries, it should stop and report — not work around the constraint by finding an open channel.
• Screenshot content scanning. Before any image is stored, shared, or processed externally, it should be scanned for PII, credentials, internal URLs, and proprietary UI elements.
• Strict output channel controls. Any image or file generated by an AI agent should be logged, and its destination should be restricted by policy — not left to the agent’s judgement.
• User confirmation for novel actions. If an agent is about to take an action it hasn’t been explicitly instructed to take — such as creating a public repository — it should surface that for approval before proceeding.

WI1 Has These Guardrails by Default

At WI1, we’ve built these protections into the platform from the ground up — not as an add-on or a compliance checkbox, but as the default way AI agents operate.

When an AI agent working inside WI1 needs to handle visual content or any file output, it operates within a controlled permission model. Agents cannot route output to unauthorised destinations. There are no public fallbacks. Screenshot-related tasks are scoped to private, authenticated channels, and any novel action outside the agent’s defined remit requires human confirmation.

The Glow Security findings are a useful reminder that the risk from AI isn’t always dramatic. Sometimes it’s an agent quietly uploading your internal billing screen to a public GitHub repo because that was the most efficient way to answer a question. Guardrails that prevent that kind of well-intentioned data leak need to be structural — baked in, not bolted on.

If you’re evaluating AI tools for your team, ask the vendor where the guardrails live. If the answer involves manual configuration or an enterprise tier, that’s worth noting.