The rule
An agent's work becomes dangerous only when all three of these meet in the same task:
- Private data. Secrets, credentials, internal configuration, anything you would not publish.
- Untrusted outside content. A fetched web page, a third-party gist or skill, a plug-in server you have not vetted. Anything that can carry instructions you did not write.
- An outbound channel. A push, a publish, a saved-snippet update, any network request that leaves the machine.
Any two of the three is ordinary work. Private data plus an outbound channel, with nothing untrusted in the loop, is you deciding what gets sent. Untrusted content plus an outbound channel, with no secrets in reach, can misbehave but has nothing worth stealing. It is the full set together that lets outside text read your secrets and pick where they go.
When a task looks like it needs all three, that is the signal to stop and split it into two pieces, not to proceed carefully. Careful is not a control here.
Why the combination is the danger
An agent treats the text it reads as instructions. It cannot reliably tell your request apart from a sentence buried in a web page that tells it to read a key and post it somewhere. That is prompt injection, and there is no setting that turns it off. Detection helps at the margins and fails in the middle, because the malicious text can be phrased as anything.
So the rule does not try to catch the attack. It removes one leg of the trip. With no untrusted content in the task, there is nothing to inject the instruction. With no secrets present, a followed instruction finds nothing to take. With no outbound channel, whatever it finds cannot leave. Break any one leg and the other two are harmless.
Where a permission list stops
Blocking risky commands with a permission list helps, but it matches command names only. It sees curl on its own line and can stop it. It does not see the same curl inside a shell script, a network call folded into a python -c one-liner, or a request made by a library three functions deep. Those all leave the machine without ever naming a blocked command.
The written rule is the guard. The permission list is a backstop that catches the obvious cases and misses the rest, so it is never the thing the safety rests on. Treating the gate as the real protection is the mistake the rule exists to prevent.
What the rule does not do
It is about combination, not about making any single ingredient safe. It does not clean untrusted content, does not hide secrets, and does not vet a plug-in server for you. It draws no line for you between trusted and untrusted, or between private and public. Those are judgments the person makes before the work starts.
Nothing enforces the split automatically. A task that quietly grows a third leg partway through, a fetch added to reach a docs page, a publish step tacked on at the end, is back in the danger zone the moment it does, and only a person watching the shape of the task will notice. The rule is a habit, not a switch.