The security problems of enterprise LLM deployments are, with few exceptions, architecture problems wearing a novelty costume. An assistant that can read every document its service account can read will eventually read one it should not have. An agent with a standing API token will eventually be persuaded to use it. Neither failure is about the model.
Four planes, four owners
Decompose the system into an identity plane, a data plane, a model plane and an action plane, and assign each an owner. Identity governs who — human or agent — is making a request and on whose behalf. Data governs what content can enter context and under whose entitlement. Model governs which models are approved, where they run and how they are versioned. Action governs what the system may do in other systems. Most enterprise incidents trace to a plane with no named owner, usually action.
The trust boundary is the context window
The single most useful architectural statement you can make is this: everything that enters the context window is untrusted input, regardless of origin. System prompt, retrieved chunks, tool output, user message — once concatenated, the model cannot reliably distinguish instruction from data. Architecture follows: never place a security decision inside the prompt. Authorisation, rate limits and approval requirements are enforced by code outside the model, on both sides of it. The prompt is where you express intent, not where you enforce policy.
Retrieval-layer authorisation, not post-filtering
The most common design defect in enterprise RAG is indexing everything and filtering the answer. Entitlements must be applied at retrieval: the index carries the source document's access control metadata, and the query executes as the requesting user, returning only chunks that user could open directly. Post-hoc filtering fails because the model has already seen the content and will paraphrase it. Two operational consequences follow — the index must re-sync when permissions change, not only when content changes, and deleted or reclassified documents need a defined eviction path.
Agents need first-class identity and scoped, short-lived credentials
Every agent gets its own workload identity, not a shared service account and not a human's token. Delegation is explicit: the agent acts on behalf of a named user with a token that carries that user's entitlements, scoped to the specific tools the task requires, expiring in minutes. Excessive agency is the risk class here, and it is bounded by design, not by instruction. The test is simple: if the worst possible sequence of tool calls, executed by a fully compromised agent, would be survivable, the scoping is right.
Mediate every tool call
Tools are invoked through a broker, never directly from the model runtime. The broker validates arguments against a schema, checks the caller's entitlement for that specific resource, applies rate and value limits, requires human approval above defined thresholds, and logs the full call with its originating conversation. This is where irreversible actions get their brake: payments, access grants, external communication and deletions should require a confirmation path that the model cannot satisfy by itself.
Observability that a SOC can actually use
Log the prompt, the retrieved source identifiers, the model and version, the tool calls with arguments and outcomes, and the final output — with retention and redaction rules agreed with privacy and legal before launch, not after. Then build detections on top: canary token appearances, retrieval of documents far outside a user's normal working set, tool-call sequences that do not match any known task pattern, and sudden shifts in refusal rate. Without these, an AI incident is unreconstructable, and unreconstructable incidents cannot be closed.
The evaluation loop is part of the architecture
A secure LLM architecture includes the mechanism that proves it is still secure. Attack success rate, false refusal rate and leakage tests run against the deployed configuration on every change to model version, system prompt, retrieval settings or tool schema. Results gate release. Production signals feed back into the test corpus. Architecture without this loop is a snapshot of one day's assumptions, and model vendors ship changes faster than architecture documents get updated.
Governance that does not stop delivery
Wrap the above in a standard: an approved model catalogue with an intake path, a risk tier that determines review depth, a small set of non-negotiable controls that apply at every tier, and a named approver. Teams should be able to ship a low-risk internal assistant in days by conforming to the pattern, while a customer-facing agent with payment authority goes through full review. Governance that treats both identically produces shadow AI, and shadow AI is the one deployment with no architecture at all.