Secure Architecture
Design AI systems with policy boundaries, isolation, logging, and safe tool access.
Written and reviewed by Eric Han · Co-founder & CTO, reopt
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.
September 2026: connect OWASP ACS to runtime controls
The OWASP Agent Control Standard provides an open foundation for enforcing declarative policies through platform middleware hooks. It is not a certificate or a legal compliance decision.
Our application pattern is to check principal, tenant, resource, allowed action, and expiry before tool execution, then apply disclosure policy before returning results. Record the decision and policy version, and test whether another tool or child agent can bypass a denial. A prohibition written only in a prompt does not implement this control.
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.