Retrieved documents, tool results and user messages all arrive on the same channel as your instructions. A model cannot reliably distinguish the text you wrote from text someone else placed in your index — which means a prompt is not a security boundary.
Six controls worth building in
01Authorization as dataPermissions belong on the tool and the role, evaluated before the call executes — not listed in prose the model can talk around.
02Confirmation gatesRefunds, captures and deletions stop before execution and wait for a human with the right role. The model proposes; a person disposes.
03Audit before the effectWrite actor, tenant, tool, arguments and run id before the side effect. A crash mid-call must still leave a record.
04Retrieved content is hostileTreat retrieval output as data to quote, never as text that can change what the agent is allowed to do.
05Secrets never enter contextKeys stay in the vault and in the tool implementation. A model that has seen a credential will eventually repeat it.
06PII stays on your networkRoute by data class — local models for traffic carrying personal data, escalation only for what is safe to send.
Where each control must not live
Where it belongs
- Per-agent allow-list on the tool registry
- Query-level scoping on every read
- Per-session counters enforced server-side
- HMAC signature plus idempotency key
- Max iterations and a wall-clock timeout
Where it must not live
- Prompt text listing what is allowed
- A filter the model is asked to apply
- “Do not call this too often”
- Accepting any POST that parses
- Asking the agent to stop when it is done
None of this is exotic security work. It is ordinary authorization, applied on the assumption that one of the participants in your system will occasionally be persuaded to do the wrong thing.
