Secure Architecture
Design AI systems with policy boundaries, isolation, logging, and safe tool access.
Key takeaways
- Secure AI architecture assumes model output is untrusted and surrounds the model and its tools with policy, isolation, and audit.
- Assign security responsibility per layer: interface auth, orchestration policy checks, model access controls, retrieval permissions, tool least privilege, and observability.
- Keep privileged tools behind deterministic policy gates, separate read tools from write tools, and run code, file, or browser execution in isolated runtimes.
- Enforce user and tenant permissions during retrieval rather than trusting the prompt.
- Watch red flags like a single prompt controlling both policy and action, retrieval ignoring document permissions, or write actions lacking approval or rollback.
Secure AI architecture assumes model output is not inherently trusted. Policy, isolation, and audit must surround the model and every tool it can influence.
Architecture Layers
| Layer | Security responsibility |
|---|---|
| User interface | Authentication, consent, and input constraints |
| Orchestration | Policy checks, prompt assembly, tool routing |
| Model access | Provider controls, data handling, rate limits |
| Retrieval | Source filtering, permissions, freshness |
| Tools | Least privilege, approvals, side-effect control |
| Observability | Logs, traces, alerts, and evidence capture |
Design Principles
- Treat model output as untrusted until validated.
- Keep privileged tools behind deterministic policy gates.
- Enforce user and tenant permissions during retrieval.
- Separate read tools from write tools.
- Use isolated runtimes for code, file, or browser execution.
- Log decisions enough for investigation without leaking sensitive data.
Red Flags
- A single prompt controls both policy and action.
- Retrieval ignores document permissions.
- Tool results can inject new instructions without sanitization.
- Write actions lack approval or rollback.