AI Agents Leaked 13,000 Screenshots: Why Enterprise Approval Controls Failed

Thirteen thousand internal screenshots from 343 technology companies are sitting in public GitHub repositories because a coding agent could not attach an image to a private pull request. 

Cybernews reported that the exposed material includes customer records, billing data, payment system screens, and unreleased product features. The agents appear to have completed the task using access they already held, but the route they took exposed data publicly.

That last detail is the story. When a private repository could not render the image, the agents created public ones, mostly under employees’ personal accounts. No policy forbade it in a form software could act on, and no control stood between the task and the result.

It would be comforting to call this an outlier. A survey of more than 900 executives and technical practitioners says it is closer to the norm. Gravitee’s State of AI Agent Security 2026 report found that only 14.4% of organizations have every AI agent go live with full security and IT approval, while 82% of executives say they feel confident their existing policies protect them from unauthorized agent actions.

The sequence is deploy first, approve later, investigate after that. The survey comes from an API management vendor, so treat the figures as directional. Directional is enough. Nobody is reporting that agents wait politely for a security review, and the screenshot leak is what that looks like when the agents are good at their jobs.

The gap between AI policy and enforcement

Look beneath the confidence. A policy is not a control, and a count of incidents tells you how often something went wrong without telling you whether you could explain it to a regulator. The harder question is a plain one. Can you prove, on demand, who authorized this agent, which data it touched, and under what rule?

The same survey puts a number on how far most organizations are from that answer. On average, only 47.1% of an organization’s AI agents are actively monitored or secured. Run that through an audit. An agent that is not actively monitored can leave critical gaps in the record. 

An agent without its own identity cannot be tied to the person who delegated the work, and agents that share credentials cannot say which of them acted. Each gap removes a link between an action and an accountable human, and an investigator needs every link.

If the honest answer is “we would need to reconstruct it,” you do not have a security gap so much as an evidence gap. A detection gap belongs to the SOC. An evidence gap belongs to the CISO and the Chief Compliance Officer together, because one must produce the record and the other must stand behind it when a regulator’s clock starts.

When an AI security gap becomes a compliance problem

The clock runs in days. Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report found that 50% of organizations cannot produce a complete AI data access audit record within one business day. Notification windows, customer contract terms, and assessor timelines do not wait for an evidence package that takes weeks.

I call the gap between confidence and enforcement governance theater, and I say it without contempt for the executives involved. They are reasoning from the best information they have: a written policy. Nobody has shown them whether that policy is technically enforced at the point where an agent reaches for data. A rule that no system enforces is a statement of intent, and auditors will read it as such.

Regulators do not regulate models. HIPAA, PCI DSS, and the financial regulators do not ask whether a clinician or a program disclosed the data, and a screenshot of a billing console in a public repository raises the same questions either way. The obligation attaches to the data, and the evidence requirement attaches with it.

That is also why a system prompt is not a compliance control. An instruction telling a model to stay away from certain material can be bypassed or changed, and an assessor will not accept “the agent was told not to” as proof of access control. Enforcement must sit with the data, independent of the model, and it must leave a record.

What must change before the next agent ships

Start by naming an owner for every agent. Not the team that built it and not the vendor whose model it calls, but one accountable person who can say what the agent may write, publish, and share, and who delegated the work. Ownership of AI security is unsettled in most organizations, and that vacuum is the cheapest gap to close.

Next, give agents their own identities and tie each one to the human who authorized it. Humans and agents are two classes of identity that belong under one governance model, with one policy and one audit trail. The goal is not independence for agents. It is attribution for everything they do, with authority scoped to each action rather than inherited whole from a developer’s session.

Then inventory every place an agent can write. List each destination an agent might use to make a human see an artifact, record who owns the account and whether the default is public, and refuse or human-gate anything world-readable outside your control. Treat screenshots and recordings as data, because they carry customer records and tokens and slip past rules written for documents.

Finally, run the test your auditor will run. Pick a recent agent action and ask your team to produce the complete evidence package covering authorization, data accessed, policy applied, and the log that proves it. Time the answer. If it takes days, that number is your real exposure, and it will persuade a board faster than any survey.

The organizations that close the approval gap will not be the ones with the longest policy binders. They will be the ones who can answer the auditor’s question before anyone asks it.

Editor’s note: This article originally appeared on our sister publication, TechRepublic.