Expert Briefing: Security Architecture for AI Adoption

Briefing overview

Teams adopt AI faster than architecture reviews can follow. The usual reply is a separate AI security stack, with its own tools, owners and handoffs. Most organizations cannot run that on top of everything else they already operate.

This briefing argues for the opposite. Most of what AI adoption needs already sits in your identity, data, API and logging layers. The work is to extend those layers to a few new kinds of component, and to decide in advance where a model is allowed to act.

The new components are models (hosted or self-run), the retrieval and data stores that feed them, the tools and APIs that agents can call, and the prompts and outputs that move between all of these.

What you will take away

• A reference view of where AI systems touch identity, data and action.

• A mapping from well-known LLM application risks to architecture controls you probably already own.

• Four decisions to settle before the first production use case.

• A rule for when an agent needs a human to approve what it does.

• A way to keep the added complexity small.

Agenda

The architecture question is about authority

A model that only answers questions from public text has a small blast radius. The picture changes when it can read enterprise data on a user’s behalf, or call tools that change things. At that point it holds authority, and architecture has to say whose authority it is, over what, and with which limits.

One consequence follows directly: authorization cannot live inside the prompt. A system prompt is an instruction to a model. It is not an access control. Anything that matters has to be enforced by a component that does not depend on the model behaving well.

Risks as architecture requirements

The OWASP list of risks for LLM applications gives a shared vocabulary. The table maps six of its entries to architectural responses. The responses are our analysis. They are not text from OWASP.

Four decisions before the first production use case

1. Whose identity does the system use? The user’s, the service’s, or a dedicated agent identity. Each answer changes what an investigator can learn from the logs.

2. What can it retrieve, and where is that enforced? If the answer is “the prompt tells it not to,” the control is missing.

3. What can it do, and which actions need a person? Draw the line by reversibility and value. Reading is not the same as sending, deleting or paying.

4. What gets logged, and who looks? Prompts, retrieved sources, tool calls and approvals each answer a different investigative question. Decide retention before the first incident, not after it.

Keeping complexity down

Complexity usually arrives through bespoke work: each team wires up its own model access, its own keys, its own retrieval and its own logging. A better pattern is a small number of paved roads. One way to call hosted models. One way to give an agent an identity. One retrieval layer that honors entitlements. One logging format.

There is a trade-off. A central gateway creates a chokepoint and can slow teams down. No shared pattern lets drift set in, and you end up auditing a dozen different designs. We would start with the shared pattern for external model calls and agent identity, and widen it only where teams show a need. That is a recommendation based on practice, not a finding from a source.

The NIST AI Risk Management Framework organizes AI risk work into four functions: Govern, Map, Measure and Manage. NIST also publishes a Generative AI Profile as a companion. In our reading, governance sets the rules, and architecture decides which rules a system is unable to break.

Next step

Run your next AI use case through the four decisions before it ships. Start with identity and data access. They constrain everything else.

Sources

OWASP Top 10 for LLM Applications (current edition) — OWASP GenAI Security Project

AI Risk Management Framework and Generative AI Profile (NIST-AI-600-1) — National Institute of Standards and Technology