TL;DR: AI tools can share company data without anyone breaking in, and the protection is a set of settings your IT team can check and prove. This post explains the risk and lists what to ask IT to do. If you'd rather start with the practical part, download the checklist spreadsheet (it opens in Excel or Google Sheets). It has the same lists with a status column for IT to fill in, and a summary tab that shows you what needs your attention.
On 29 September, security researchers at Glow reported that AI coding tools had published more than 13,000 internal screenshots into more than 900 public code repositories (a repository is a shared folder of code and files). The screenshots included customer billing records, internal screens showing client names and money movements, and unreleased features. Glow says more than 300 organisations were affected. Glow sells security software, so those counts are its own. The mechanism, though, is documented in the tools' own logs, and that is the part worth acting on.
Those were screenshots from developers, but the risk isn't limited to code. It applies to anything an AI tool can reach and share: files in a shared drive, email, chat, customer records.
Nobody hacked anything
The tools were doing what they were asked. A private repository can't show images in a code review, so one tool decided the fix was to host the pictures elsewhere. Its own log says: "The only way to satisfy both 'reviewers see the images' and 'nothing but index.html in the repo' was to host the PNGs elsewhere." It created a public repository.
If your people use AI tools, the question isn't whether they're careful. It's what each tool is allowed to do when it decides how to finish a job.
A rule isn't a lock
The usual response is a policy: tell staff, and tell the tool, never to put company material in public. A policy is a sign on the door saying "do not enter". An AI tool has no instinct to respect a sign. It works out the quickest way to finish the task, and if the door is unlocked, it walks through. The agent in that log was following its instructions.
The fix is to change what the tool is able to do, so the door is locked whatever it decides.
Four questions to ask about every AI tool
- What can it reach? Which files, mailboxes, chats or code. Many assistants act with the same access as the person using them, which means loose internal sharing becomes loose AI access. Ask the vendor to confirm how theirs works.
- What can it send out? Can it create a public link, share with people outside the company, or push to an account you don't control?
- Who approves before something leaves? If the answer is nobody, that's the gap.
- Who would notice, and how fast? Without a regular check, you find out from a customer or a researcher.
The checklist below turns those four questions into things IT can do and prove. We've given the steps for three common platforms. If you use something else, ask IT for the same thing by its plain description. Other providers have similar controls.
The gap most checklists miss: personal accounts
Glow found that 93% of the exposed images sat in repositories under employees' personal accounts, not company ones. Company settings control what the company owns. They don't reach a personal account.
On GitHub, the one control we found that does is called Enterprise Managed Users: the company creates and controls the accounts, and GitHub's documentation says such accounts can't publish public repositories or collaborate with accounts outside the company. It needs the Enterprise Cloud plan. For everything else, the levers are limiting which apps can connect to company accounts (the sections below), keeping company work inside company accounts, and the tool inventory in the first list. That's why the checklist includes questions for people as well as settings.
What to ask IT to do
These settings need an administrator. For each one, ask IT to send back a screenshot. Some settings depend on your plan, so "we can't do this on our plan" is a valid answer to send back.
If you use GitHub (code)
| Ask IT to | Where to find it |
|---|---|
| Stop members creating public repositories | Organisation Settings, Member privileges, Repository creation |
| Stop members changing a repository from private to public | Member privileges, Repository visibility change: untick "Allow members to change repository visibilities" |
| Restrict the access keys tools use to act as a person (GitHub calls them personal access tokens) | Settings, Personal access tokens: restrict the older type, require an owner's approval for the newer type, and set a maximum lifetime |
| Restrict which third-party apps can connect | Settings, OAuth app access restrictions (on by default for new organisations) |
| Turn on the automatic check that blocks passwords and keys from being uploaded (push protection) | The organisation's security settings |
| If you use GitHub Copilot: limit what it can reach on the internet | Settings, Copilot, Internet access: firewall on, recommended list only, repositories not allowed to override |
| If you use Copilot's cloud agent: allow it only on repositories you choose | The organisation's Copilot policy, and each repository's opt-out |
| Set up a monthly check for new public repositories | Settings, Logs, Audit log: filter for action:repo.create. It keeps 180 days and exports to CSV. |
If you use Google Workspace (files, email)
| Ask IT to | Where to find it |
|---|---|
| Turn off sharing outside the company, or limit it to named partner domains | Admin console, Apps, Google Workspace, Drive and Docs, Sharing settings, Sharing options. Changes can take up to 24 hours. |
| Show a warning on files owned by or shared with people outside the company | The same page: the external file indicator |
| Block third-party apps from company data until someone has approved each one | Admin console, Security, Access and data control, API controls: set unconfigured third-party apps to be blocked, and mark Gmail and Drive as restricted so only apps you trust can reach them. All Workspace editions include this. |
If you use Microsoft 365 (files, email)
| Ask IT to | Where to find it |
|---|---|
| Stop "Anyone" links, which let anyone with the link open a file without signing in | SharePoint admin center, Policies, Sharing, External sharing: choose guests who sign in, or only people in your organisation, instead of "Anyone". If you keep "Anyone", set links to expire and to view-only. |
| Make the default link only work for named people or colleagues | The same page, More external sharing settings, File and folder links |
| Limit external sharing to named partner domains | The same page: Limit external sharing by domain |
| Stop staff approving third-party apps themselves, and route requests to an administrator | Microsoft Entra admin center, Enterprise apps, Consent and permissions, User consent settings, plus the admin consent workflow. Needs a Global Administrator. |
| Check the audit log is on, and set up a monthly look at file-sharing activity | Microsoft Purview, Audit. It's on by default and keeps records for 180 days (one year on E5 licences). |
For any tool: items that need a person
- List every AI tool in use, what data each can reach, and whether it signs in with a company or a personal account. Staff-bought tools count, because that's where the exposure was.
- Ask each AI tool's vendor what its agent can do by default and which of those actions you can switch off. Ask for the answer in writing.
- Remove access for anyone who has left. IT compares the people in each system (for example the GitHub organisation, under Organisation, People) against HR's current staff list, removes anyone who shouldn't be there, and does the same for any AI tool with its own user list. Glow found exposure in accounts belonging to people who had since left.
- For code: search public GitHub once for your company. IT searches for your company name, product names and internal system names. It takes about ten minutes. They send back the date and either "found nothing" or the list of results.
- Name one person who will cut off access, change any exposed passwords or keys, and decide whether you have to notify anyone if personal data was involved. Under Singapore's PDPA, notification rules may apply.
Download the checklist as a spreadsheet. It has the lists above with a status dropdown for IT to fill in, an AI tool inventory, and a summary tab that shows you what needs your attention.
How to hand this to IT, and what to read when it comes back
Forward this note along with the list above:
Recent research found AI coding tools publishing internal company screenshots to public repositories, mostly from employees' personal accounts. Please work through the lists that apply to us by [date]. For each item, send back either a screenshot or short answer showing it's done, or tell me "can't do this on our plan" or "needs a decision". If an item isn't clear, tell me rather than guessing.
When it comes back, you don't need to judge the settings. You're looking for three things:
- Any "can't do this on our plan". That's a budget decision, and it's yours to make.
- Any answer to the tool list that shows work or data going through personal accounts.
- No name against the last item. If nobody owns the response, nothing will happen in the first hour of an incident, when it counts.
Everything else came with a screenshot, so you can take it as done.
What we don't know
The Glow count of affected organisations is Glow's own figure and hasn't been independently confirmed. The settings above come from each vendor's current documentation, but menus and plan requirements change, so IT should confirm them in your own account. We haven't included a monthly sharing check for Google Workspace, because we haven't verified how it works. And none of this makes an AI tool safe, only less able to share things on its own. If you want to go deeper on why a chat window isn't a process, see Why Dropping Files Into ChatGPT Isn't a Business Process.