Five signs an AI script is uploading more than it should

It has never been easier to write a small program that calls an AI service. A few lines read some files, send them to a model, and save the result. Summarise my notes every morning. Tag new photos. Draft replies to support emails. These scripts are genuinely useful, and they have a habit of growing: more folders, more data, more destinations, a schedule nobody revisits.

Most never cause a problem. But "uploads more than it should" is one of the most common ways AI automation goes wrong, through a bug, a careless change, a compromised dependency or a prompt injection. Here are five signs to look for, roughly in order of how easy they are to spot.

1. The volume doesn’t match the job

Requests to language models are mostly text. A request to summarise a page or classify a message is measured in kilobytes. Images and documents are larger, but still bounded by what the task needs.

When a script that "summarises my calendar" is sending tens or hundreds of megabytes to an AI endpoint, something is different from what you think it does. Perhaps it is attaching whole documents instead of excerpts, or a loop is re-sending the same data, or it has started including a directory you did not intend.

How to check: watch the process’s network usage while it runs. On Windows, Resource Monitor’s Network tab shows bytes per process; on macOS, Activity Monitor’s Network tab does the same. A sustained upload far larger than the input you expected is the signal.

2. It runs when nobody asked it to

Scheduled jobs are the classic forgotten agent. A task created during an experiment, a cron entry, a login item or a cloud function with a long-lived key keeps running long after the experiment ended. Activity at 3 a.m. from a tool you think of as interactive is worth a look.

How to check: review scheduled tasks (Task Scheduler on Windows, crontab -l and launch agents on macOS and Linux) and login items. For each one that calls an AI service, ask whether it still has a job to do.

3. It talks to destinations you didn’t expect

A script built against one model provider should, broadly, talk to that provider. If it is also connecting to a second AI provider, a file-sharing service, a paste site or an unfamiliar hostname, that is new behaviour. Sometimes the explanation is benign: a library added a fallback provider, or telemetry was switched on by default. Sometimes it is not.

How to check: list the connections the process makes while it runs. Look at the hostnames, not only IP addresses. A single process reaching several different AI providers is a pattern worth understanding even when each connection looks normal on its own.

4. It reads far more than it needs

Scripts often start with a narrow input, such as "the notes folder", and later get pointed at something broader, such as "my documents", "the home folder" or "the whole drive", because it was easier than fixing a path. Every file in that scope is a candidate for the next prompt.

Look especially for access to folders that never belong in an AI request: SSH keys, cloud credential files, browser profiles, password manager exports, tax and medical documents.

How to check: read the script’s configuration and the paths it walks. If you have a tool that shows file access by process, look for anything outside the folder the job is about.

5. It starts other programs

A script that only reads and sends data should not need to start a shell, launch a browser or run other programs. Agents that do these things exist for good reasons, but when a simple automation starts spawning processes, its capabilities have grown beyond its original job, and so has what can go wrong.

How to check: look at the process tree while it runs. Child processes such as cmd.exe, powershell, bash, curl or a headless browser are the things to notice.

What to do when you spot one

1. Pause it. Disable the schedule or stop the process, so the question can be answered calmly.
2. Rotate the key it uses. If the script may have been misbehaving, assume its API key could be in the wrong hands too. Issue a new one with limits.
3. Narrow its inputs. Point it at exactly the data it needs; exclude credential and personal folders explicitly.
4. Set provider-side limits. Most AI providers let you cap spending and usage per key, which also caps how much data a runaway job can push.
5. Check the dependencies. Update and review the libraries it uses, especially recently added ones.
6. Write down what it is for. A one-line note next to the schedule saves the next person, often future you, a lot of guessing.

A note on false alarms

Each of these signs has innocent explanations. A transcription tool legitimately uploads large audio files. A backup job that uses AI to tag photos legitimately runs at night. A coding agent legitimately starts a shell to run your tests. The point is not that any single signal proves wrongdoing, but that each one is a moment to compare what the script does with what you believe it does. When the two match, approve it and move on. When they don’t, you have found something worth fixing early.

Letting the computer do the watching

All five signs are observable from the outside: bytes sent per process, time of activity, destination hostnames, file locations touched and child processes. That is why GreyArm watches them continuously. Large uploads while connected to an AI service, a process talking to several AI providers, shells spawned by AI-connected processes, access to credential material and agents seen for the first time are each raised as findings, with the process, the destination and the numbers, so you can see the problem at the moment it starts rather than in next month’s bill.