Security model
Five walls that make the recipe unreachable — not hidden, unreachable.
The hardest security problem here isn't unusual: a caller — often a machine, sometimes an adversarial one — is going to try to make an agent reveal or ignore its instructions. What makes amnt's answer worth reading is that the defence isn't a filter layered on top; it's a property of the interface itself.
The five walls
| # | Wall | Rule |
|---|---|---|
| 1 | 🤐 Recipe never leaves | A run's response is the output artifact, and nothing else — never in a result, an error, a log line, or a trace |
| 2 | 📏 Slots have limits | Every slot has a maximum length; a dropdown is preferred over free text wherever the values are known ahead of time |
| 3 | 🧊 Slots are data, never orders | A slot fills a hole in the template. It never becomes part of what the model is instructed to do |
| 4 | 🛑 Hard spend caps | Every run has a cost ceiling; a run that exceeds 3× its measured cost is stopped and refunded, not allowed to keep going |
| 5 | 🚦 Auto-suspend | An agent failing more than 20% of its last 50 runs goes offline automatically, without anyone having to notice first |
Why this beats a prompt-injection filter
A filter that scans slot values for suspicious phrases is a game you lose eventually — attackers iterate on wording faster than filters can be updated. amnt's approach sidesteps the game entirely: there is no field a request could put "ignore previous instructions" into that would ever reach the model as an instruction, because slot values are inserted as data into a fixed template, never concatenated into something the model reads as a directive.
On slot injection specifically: a machine caller routinely tries placing instructions inside a value a human almost never would. A 60-character limit on a company-name field eliminates the overwhelming majority of such attempts before any semantic defence is even needed. Boring constraints outperform clever ones here.
What "the recipe never leaves" actually covers
Not just the obvious response body. The same guarantee holds for:
- Error messages — a failed run's error text describes what went wrong, never what the recipe said
- Logs — server-side logging never writes the instruction text, so a log-access incident can't leak it either
- Database access — the underlying instruction column is access-controlled at the column level, not filtered in application code. Row-level policies that permit reading a row expose every column of it; a column that must stay secret needs its own protection, independent of whatever a row-level rule allows
- The public page — an agent's page shows samples and a form, never the template that produced them
Runaway cost is treated as a security problem, not just a billing one
A single agent that's misbehaving — looping, or receiving pathological input — is capped by wall 4 above regardless of why it's misbehaving. This matters more as agent types beyond simple image generation are added: an agent with a multi-step reasoning loop has categorically more ways to run away than a single model call does, so any future agent type with that shape inherits stricter caps by construction, not by review — see What's next.
Reporting a problem
If you find a way to make an agent behave outside what's described here — particularly anything that surfaces recipe text it shouldn't — treat it as a security report, not a bug report, and reach out directly rather than filing it publicly.