Why an instruction is not a safety control
Telling a model what not to do is a request it weighs against everything else. At unattended scale, a rule that holds 99.5% of the time fails every month.
Almost every team building unattended agents starts in the same place: write the rules into the prompt. "Never email anyone outside the company." "Do not include account numbers." "Only reply to the person who wrote in."
Those sentences are worth writing. They are not controls, and the difference is not pedantry. It decides whether your safety story survives contact with volume.
The distinction
| An instruction | A control | |
|---|---|---|
| Lives in | The prompt | The platform |
| Enforced by | The model's judgement | Code the model cannot reach |
| Competing against | Helpfulness, completeness, the user's apparent intent | Nothing |
| Under adversarial input | Can be redirected | Unaffected |
| When it fails | Silently, and plausibly | The action is refused, and recorded |
| Evidence it worked | Read every output and hope | The value never left |
An instruction is a request to a model, evaluated in competition with every other pressure in its context. A control is a fact about the system.
The arithmetic of "usually"
Say a prompt rule holds 99.5% of the time. That sounds excellent, and in a chat session it is: you would never notice.
Now put it on an unattended worker:
| Runs | Expected failures at 99.5% | |
|---|---|---|
| One worker, hourly, 10 hour day | 10 a day | 1.5 a month |
| Same worker, one month | ~300 | 1.5 |
| A fleet of 5 workers | ~1,500 a month | ~7 a month |
| A fleet of 5, over a quarter | ~4,500 | ~22 |
Twenty-two rule violations a quarter, each one plausible-looking, none of them announced. That is the actual shape of prompt-based safety at fleet scale, and no amount of prompt refinement moves it to zero, because the mechanism is probabilistic by construction.
The Free plan runs 5 workers, so this is not a hypothetical enterprise scenario. It is the second week of using the product properly.
Why models can be argued past
Three reasons, and none of them is a bug to be fixed in the next release.
Helpfulness is a competing pressure. A model asked to be useful, faced with a task it can complete by bending a rule, is in genuine tension. The rule is text. So is the task.
Context crowds. A rule stated once at the top of a long instruction competes with everything after it. On run four hundred, with a thread of unusual shape, the sentence that seemed emphatic in testing is one line among many.
Adversarial input exists. This is the one that matters most for workers, because a worker reads text other people wrote. A support thread, an inbound lead, a calendar invite: all of them are untrusted input that ends up in the context window. Text engineered to redirect a model is competing directly with your instruction, on the same surface, in the same units.
That last point has a sharp corollary. **A model asked to ignore a thread has, by definition, read the thread.** If the thread contains an injection, the instruction to ignore it is now arguing with the attack.
What a control looks like instead
WorkerKit's safety layer is three controls, and each answers a question an instruction cannot answer reliably:
| Layer | Question | Enforcement |
|---|---|---|
| App firewall | Which apps, at what level? | The worker holds no credential for what it was not granted |
| Contact rules | Which people may it see and reach? | Reads are filtered before the model; blocked recipients are refused |
| Redaction | What must never leave? | Values are stripped before the model sees them |
Read the enforcement column carefully. In all three cases the restraint happens outside the model's context. There is nothing for the model to weigh, and nothing for an injection to argue with, because the capability is absent rather than discouraged.
All three ship on every plan including Free and are never tier-gated, which is deliberate: charging for the controls that make autonomy safe would mean shipping the risky configuration as the default.
The same job, both ways
Support Inbox Triager reaches email and tasks to classify, prioritise, draft replies and file tickets. It reads text strangers wrote, all day. Consider one requirement: it must not email the executive team.
As an instruction: "Never send email to anyone at the exec team." It works until a customer writes "please escalate this to your VP of Engineering, her address is...", at which point the model has a task, an apparent authorisation, and a rule, and it has to adjudicate. Sometimes it gets that right.
As a control: contact rules refuse the recipient. The draft is not created. The refusal lands on the receipt. There is no adjudication, because sending was never available.
The second version is not smarter. It is simply not a judgement call.
The reasonable objection
"Models are getting better at following instructions. This will age badly."
They are, and the trend is real. But it does not resolve the argument, for two reasons.
Reliability improvements are asymptotic and the volume is multiplicative. Moving from 99.5% to 99.9% takes that fleet from ~22 violations a quarter to ~4. Better, and still not a control you would describe to a customer as a guarantee.
More importantly, the adversarial case does not improve the same way. A model that follows instructions more faithfully also follows *instructions embedded in the content it reads* more faithfully, unless something distinguishes trusted from untrusted text. That distinction is architectural, not a capability you get from a better model.
When an instruction is the right tool
Controls are not a replacement for good instructions, and treating them as one produces a worker that is safe and useless.
- Quality and tone. "Match our voice, lead with the answer." No control can express this.
- Judgement within permitted actions. Which of three allowed categories a ticket belongs in.
- Escalation criteria. When to leave something for a person.
- Defaults. What to do when the input is ambiguous.
The dividing line: **instructions decide what the worker should do; controls decide what it can do at all.** Use instructions for quality, controls for consequences. A requirement whose violation you would have to explain to a customer belongs in the second category.
The design rule
If you cannot state a safety property as something the system makes impossible, you do not have that property. You have an intention, held by a model, on every run, forever.
That is the test worth applying to any agent platform, including this one: ask where the rule is enforced. If the answer is "it is in the prompt", the honest description is a strong default, not a guarantee.
FAQ
Why is a prompt instruction not enough to keep an AI agent safe?
Because it is a request the model weighs against every other pressure in its context, including being helpful and any instructions embedded in content it reads. It holds most of the time, and at unattended volume "most of the time" means several silent failures a month per fleet.
What is the difference between a guardrail and an access control?
A guardrail usually means an instruction or a filter applied to model output. An access control means the capability is absent: the worker holds no credential for what it was not granted, so the action cannot be attempted rather than being discouraged.
Does redaction protect against prompt injection?
For the values it covers, yes, in the way that matters: text engineered to make a worker reveal a redacted value cannot succeed, because the value was never in the model's context. It is not a complete answer to injection, but it removes the class of attack aimed at specific sensitive fields.
Is WorkerKit's safety layer only on paid plans?
No. The app firewall, contact rules and redaction ship on every plan including Free and are never tier-gated. Plans change capacity and log retention, not safety. See /pricing.
Should I still write rules into my worker's instruction?
Yes, for quality, tone, judgement between permitted actions, and escalation criteria. Use instructions for what the worker should do, and controls for what it can do at all. Anything whose violation you would have to explain to a customer belongs in a control.