Securing an AI agent: enforce limits outside the model
Listen to this article
A system prompt is not a security boundary. Every limit that matters has to be enforced by the runtime that executes the agent's tool calls. Treat anything the model reads, including web pages, emails and tool output, as untrusted input.
What is the threat model?
Prompt injection turns content into instructions. An agent with a shell, an HTTP client and credentials can be steered by a single fetched page. The question is not whether the model can be fooled, but what it can reach when it is.
Which controls belong in the runtime?
| Risk | Control |
|---|---|
| Unplanned action | Default-deny policy decision on every tool call |
| Destructive command | Refused before execution |
| SSRF | Internal addresses refused when fetching URLs |
| Credential theft | Provider keys sealed at rest with AES-256-GCM |
| Untrusted MCP server | Explicit grant, server by server |
What does Kaiin do?
Each action goes through a Rego policy whose default is allow := false. An agent can only use its declared capabilities and the MCP servers granted to it. A refused URL returns one generic error, so the model cannot probe which internal addresses exist.
What does the Cortex SDK leave to you?
The Cortex SDK is deliberately explicit. Unset, host gates nothing, while serve allows every tool and runs commands on the machine. sandbox.Direct is not confinement. Read-only detection is a prefix allowlist, not a shell parser, so wire an Approver and a real sandbox before exposing an agent.
What should you check in any agent stack?
- Is the default allow or deny?
- Is policy evaluated outside the model loop?
- Can a repository or a page add tools?
- What can a tool reach on the network?
- Are secrets redacted from tool results?