Chapter 10 — Designing Secure LLM Architectures
Tenth post of the chapter-by-chapter walkthrough of LLM Primer VII: AI Security. The chapter that treats architecture as the primary security discipline — because the safest configuration of a probabilistic component is one whose blast radius is bounded by structure, not by the component's own restraint.
Why this chapter exists
The chapters of Parts I–III have named the threats and the model-side defences. Chapter 10 walks the architecture around the model — the isolation boundaries, validation tiers, policy engines, API contracts, and zero-trust principles that give the system its structural properties. The premise is unchanged from earlier security engineering: assume compromise, contain damage, make the compromise legible. What is new is that the component to contain is a natural-language-driven orchestrator whose instructions can arrive through any input channel. The architectural patterns transfer from earlier eras; the specifics of how they apply to LLMs are where this chapter does its work.
10.1 Isolation bounds the blast radius
An isolation boundary is a deliberate seam across which a component on one side cannot directly affect a component on the other without passing through a controlled interface. The security reason for isolation is that compromise damage is bounded by what the compromised component could reach through its legitimate interfaces. For LLM systems the most important isolation question is between the model and everything else the system has access to. A model running in a process with unrestricted filesystem access, unrestricted network access, and a shell-execution tool without an allow-list has a large blast radius. A model whose process runs in a sandbox with a defined syscall set, whose network access goes through an egress proxy with domain-level allow-listing, whose tools are invoked through capability tokens the surrounding code issues per request, has a much smaller one. The pattern extends to code execution — sandbox tools like the ones OpenAI and Anthropic use for their code-interpreter environments run generated code in ephemeral gVisor or Firecracker VMs — and to browsing, where headless browsers run in isolated network namespaces with no access to internal endpoints. Isolation is a design decision made before any specific attack occurs, and it is the cheapest security investment per unit of blast-radius reduction the field offers.
10.2 Validation is layered, and policy is declarative
A single validation point is a single point of failure. Production LLM endpoints typically compose five layers between the client request and the response. Authentication verifies the principal's credential. Request validation checks the request against the API's schema — types, ranges, lengths, character sets. Policy evaluation asks whether the authenticated principal, the validated request, and the current system state permit this action. The model call runs with the system prompt, the validated user input, the tool list scoped to what policy permits, and the output constraints. Output filtering checks the response for content that should not be returned — leaked secrets, prohibited content, unsafe tool calls — before it is sent. Policy logic grows over time and, if scattered across application code, becomes the union of many conditionals that is hard to inspect, test, or evolve. The field has converged on separating policy from code. Open Policy Agent (OPA), a CNCF project, evaluates policies written in Rego. AWS Cedar, released in 2023, is a more focused authorisation language with formal verification properties. Both are production-ready; the choice is usually organisational alignment. Policies become versioned, reviewable artefacts, and the effective security policy of the system is always readable in one place.
10.3 Zero-trust applied to model calls
The API is the contract between the LLM system and its callers. Secure API design is the discipline of shaping the contract so its invariants survive contact with adversarial callers. Explicit input schemas — strict types, ranges, allow-listed enumerations — cost little and bound the implicit trust the API places in the caller. Structured error responses that do not leak internal state avoid the intelligence gathering that vaguely worded errors enable. Idempotency keys, request IDs, and versioning give the system observability into the caller's behaviour without requiring extra state. The zero-trust model, articulated in Google's 2014 BeyondCorp paper and formalised in NIST SP 800-207 in 2020, extends the principle: no caller is trusted by virtue of network location. Every request authenticates, is authorised against explicit policy, is evaluated against device and context, and is logged. Applied to LLM systems the model call itself becomes a principal — a request from the model to a downstream tool authenticates as the model, carries the identity of the human on whose behalf the model is operating, and is authorised against policy that knows both identities. Capability tokens with narrow scope and short TTL are what make this compositional. The result is that a compromised prompt cannot elevate into full system compromise because the model's own capabilities are bounded by tokens the surrounding code issued for a specific request.
What Chapter 10 sets up
Structure without visibility fails invisibly. Chapter 11 examines the observability layer that turns architectural defences into a system that can be operated — what to log when an LLM is in the loop, how to structure telemetry to serve real-time alerting, after-the-fact investigation, capacity planning, compliance, and continuous evaluation from the same records. The OpenTelemetry GenAI semantic conventions, which began standardising LLM-specific spans and attributes in 2024, provide the vendor-neutral foundation. Specific implementations — Langfuse, Helicone, Arize Phoenix, Datadog LLM Observability — sit on top with different trade-offs. Chapter 12 then handles the identity and access dimension — OAuth, mTLS, RBAC versus ABAC, multi-tenant isolation, rate limits, and the enterprise governance controls that make the system usable in regulated environments.
Next — Chapter 11: Observability, Logging, and Incident Response. What to log with OpenTelemetry GenAI conventions, how to detect abuse patterns, and how to run a NIST-shaped incident response for a system whose failures are probabilistic.
