Which files should an AI agent never write?
Most files an AI writes are inert until a person opens them. A small category is different: the file itself is an instruction that a system will execute automatically, triggered by an event the person set up earlier and may not be thinking about when the assistant writes the file. That distinction matters more than folder permissions.
What makes a file a command rather than content?
A document, a spreadsheet, an image — these sit still until a person chooses to act on them. The person remains the proximate cause of whatever happens next. A different category of file is read and acted upon by a runtime, a scheduler, a hook, or a daemon without a human decision intervening at the moment of execution. The person's decision happened earlier, when they wired the trigger up. By the time the assistant writes the file, that decision is already in the past.
The category includes event hooks that fire when code is pushed or merged, scheduled task definitions that run on a timer, deployment manifests that a pipeline applies automatically, and configuration files that a service reloads without a restart. What unites them is not their format or extension — it is that execution is decoupled from authorship in time. The assistant finishes, the session closes, and then the file runs.
- Inert file
- Requires a deliberate human action — opening, running, or invoking — before anything happens. The person is present at the moment of effect.
- Latent-execution file
- Read and acted upon by a runtime or scheduler at a trigger the person configured earlier. No human decision intervenes at the moment of execution.
- Trigger
- The event or schedule that causes a latent-execution file to be read: a code push, a clock tick, a service reload, a pipeline stage completing.
- Scope creep
- The gap between the folder access a person grants and the actual reach of the files written inside it. Staying inside the folder is not the same as staying inside the intended blast radius.
Why does staying inside the granted folder not make this safe?
Folder permissions answer the question 'where can the assistant write?' They do not answer 'what will happen when something reads what was written there?' A hook definition sitting in a repository's designated hooks directory is exactly where it belongs — and exactly where a version-control system will find and execute it on the next qualifying event. The permission was correct. The effect was not visible at the time of writing.
This is the core asymmetry. The person granting access was thinking about the task at hand. The runtime reading the file later is not consulting anyone; it is following a rule set up long before. An assistant that treats folder access as a proxy for harmlessness is reasoning about the wrong thing. The question to ask is not 'am I allowed to write here?' but 'will this file cause something to happen without a human present to observe it?'
| File type | Who acts on it | Human present at execution? |
|---|---|---|
| Document or report | A person who opens it | Yes |
| Script invoked manually | A person who runs it | Yes |
| Scheduled task definition | A timer or daemon | Not necessarily |
| Event hook | A runtime responding to a trigger | Not necessarily |
| Deployment manifest | A pipeline on merge or tag | Not necessarily |
When should an assistant decline to write a file in this category?
The right default is to name the category, explain why it sits outside what the assistant should author, and offer to draft the logic in a form the person will paste in themselves. That keeps the person as the proximate author of the instruction. They read it, they understand it, and they make the deliberate act of placing it where the runtime will find it.
There are narrower cases where the person has explicitly set up a workflow and understands the trigger — an experienced developer who has asked for a hook definition and knows exactly what will fire it. Even then, the assistant should state plainly what the file will do and when, rather than treating it as an ordinary deliverable. The goal is not to be unhelpful; it is to make sure the person's decision is informed and present, not assumed from a permission granted earlier.
- Name the category, not just the specific file, so the person understands the general principle.
- Offer the logic in an inert form — a commented block, a prose description, a draft to be copied — rather than the finished file.
- If you do write the file at explicit, informed request, state what triggers it and what it will do before the session ends.
- Never treat folder access as evidence that latent execution was intended.
Does this apply to AI agents running autonomously overnight?
It applies with more force. An agent pursuing an objective unattended is already operating in the gap between a human decision and its effects. If that agent also writes files that will themselves execute later, the chain of deferred decisions lengthens further. The person's original instruction is now separated from the eventual effect by two layers of automation, each with its own timing.
GROX's Overnight Engine is designed to pursue objectives within limits set in advance — size caps, stop conditions, approval requirements — precisely because the person is not present to observe each step. The same logic applies to any autonomous agent: the scope of what it can cause to happen should be legible and bounded at the moment the person sets it running, not discovered later when a hook fires or a pipeline deploys.
An agent that writes latent-execution files during an unattended run is expanding its own blast radius beyond what the person could have reviewed. That is the clearest case for the rule: if the file will run later without a human present, the human should be the one to write it.
Common questions
What is a latent-execution file?
A latent-execution file is one that a runtime, scheduler, or automated system reads and acts upon at a trigger — a clock tick, a code push, a service reload — without a human making a decision at that moment. The person's decision happened earlier, when they configured the trigger. The file executes in their absence, which is what distinguishes it from an ordinary document or manually invoked script.
Why can't an AI just write the file and let the person review it before the trigger fires?
In practice, the window between writing and triggering is often short, invisible, or forgotten. A hook fires on the next push, which may happen seconds later. A scheduled task runs overnight. The person who granted access may not be the person who next pushes code. Relying on review-before-trigger assumes a coordination that frequently does not happen, and the cost of it failing is execution without oversight.
Is it ever acceptable for an AI agent to write a file that will execute automatically?
At explicit, informed request — where the person understands the trigger, has reviewed the logic, and is making a deliberate choice — it is a judgement call rather than an absolute prohibition. The assistant should still name what the file is, what will cause it to run, and what it will do. The principle is not 'never' but 'the person must be the informed, proximate author of the instruction, not an assumed one.'
How is this different from an AI running code directly?
When an AI runs code directly, the effect is immediate and observable in the same session. The person can see the output, stop the process, or undo the action. A latent-execution file defers the effect to a future moment the person may not be watching. The risk is not the action itself but the absence of anyone present to observe or halt it when it eventually fires.
If you want an agent that pursues objectives unattended within limits you set and can read back, GROX describes how its Overnight Engine and approval controls work on the home page.