AAISM lesson 9: AI security architecture
A secure AI architecture places controls in layers around the model, because the model itself cannot be trusted to enforce them. The chain runs from users and applications through an access and gateway layer, then the model and any agents, the data stores that feed it, and the infrastructure underneath, with logging across all of them. Subtopic 3A opens the technical domain, the largest at 38%, and two supporting tasks apply: design and implement security architecture for AI, and advise on how AI architecture integrates into enterprise architecture.
The layers
Users and applications. Every caller, human or system, is identified. Applications that embed AI are inventoried like any other.
Access and gateway with guardrails. A central gateway authenticates callers, applies rate limits and quotas, filters inputs for known abuse patterns, filters outputs for sensitive or harmful content, and records each request. Putting this once in front of all model traffic gives consistent policy and a single place to change it; building it into every application guarantees drift. Guardrails reduce risk but are not absolute, which is why the layers behind them still matter.
Model and agents. The model runs with the narrowest possible permissions. An agent that can call tools is a principal in its own right, with its own identity, scoped credentials and an approval step for consequential actions (see AI agents explained). Training and production environments stay separate.
Data stores and retrieval. Retrieval-augmented generation pulls documents into the prompt, so the retrieval layer must enforce the asker’s permissions; otherwise the model becomes a way around existing access control (see RAG explained). Vector stores hold derived but sensitive content and get the same classification and protection as the source.
Infrastructure. Hardened compute, network segmentation, secrets management, encryption of weights and data, and protected model registries.
Logging and monitoring. A side bar rather than a layer: prompts, outputs (within privacy limits), tool calls, safety events and query patterns flow to a monitoring capability.
Zero trust applied to AI
The zero trust ideas of never trusting by location, verifying explicitly and assuming breach translate directly:
- Verify every caller and every tool call, not just the first login.
- Treat model output as untrusted input to the next component. A model that produced a command or a query has not made it safe to run.
- Treat retrieved and uploaded content as untrusted, since it may carry injected instructions.
- Assume the model can be manipulated and size permissions for that case.
The practical test is blast radius: if the model is fully manipulated, what is the worst thing it can do?
Enterprise architecture and secure-by-design
AI should not arrive as a set of separate side projects. In enterprise architecture terms it becomes a shared capability: approved platforms and model options, a reference pattern for common use cases, standard integration points for identity, data and logging, and an architecture review for deviations. This lets the security manager approve a pattern once rather than every project from scratch.
Secure-by-design means requirements are set before build: threat modelling at design time, defined trust boundaries, data flows documented, safe defaults such as deny-by-default tool access, and security acceptance criteria that the later release gates (lesson 10) will test.
Worked example
A 400-person insurer lets three teams build assistants. Each team calls the model provider directly with its own key, one hard-coding the key in a script. The security architect introduces a gateway that holds the provider credentials, authenticates teams through the corporate identity provider, logs all traffic, and applies output filtering. Retrieval is changed to query the document store using the end user’s identity. The claims agent loses its right to write to the policy database and instead drafts changes for human approval. The security team has not made the model safer; it has made the consequences of model failure smaller and visible.
Easy to confuse
- Guardrail vs access control. A guardrail judges content; access control decides who may do what. Neither replaces the other.
- Gateway vs firewall. A gateway understands prompts and responses; a network firewall sees addresses and ports.
- Model permissions vs user permissions. An agent acting for a user should not hold more rights than that user.
Key points
- Controls surround the model; the model is not trusted to enforce them.
- A central gateway gives consistent filtering, rate limiting and logging.
- Retrieval must respect the asker’s permissions.
- Zero trust for AI means verifying calls, distrusting output and limiting blast radius.
- Reference patterns and architecture review make AI governable at scale.
Check yourself
Question 1. A retrieval-based assistant lets any employee ask questions across the whole document store, including HR files. Which design change BEST fixes this?
- A. Add an output filter for the word confidential
- B. Encrypt the document store at rest
- C. Make retrieval enforce the requesting user’s access rights
- D. Move to a more capable model
Show answer
Answer: C
Retrieval that applies the asker’s own permissions stops the model returning documents the person could not otherwise open. Output filters are probabilistic, encrypting the store does not change who retrieves, and a stronger model does not enforce access.
Want more questions like this? Full AAISM practice tests →
Question 2. Several teams call a model provider with separate keys and no shared logging. What should the security architect recommend FIRST?
- A. Mandatory training on key handling for all developers
- B. Route all model traffic through a managed gateway with central credentials and logging
- C. Add a second model provider
- D. Wait for the first incident before changing
Show answer
Answer: B
A central gateway holding credentials and logging all traffic gives one policy point and visibility. Training addresses behaviour, not structure; a second provider adds exposure; waiting for an incident is reactive.
Want more questions like this? Full AAISM practice tests →
Question 3. Which statement BEST applies zero trust to an AI agent that can call internal tools?
- A. Give the agent its own identity, least-privilege scopes and approval for high-impact actions
- B. Trust the agent because it runs inside the corporate network
- C. Trust the agent after one successful security test
- D. Let the agent use a shared administrator account for simplicity
Show answer
Answer: A
The agent is a principal that must be verified per call and limited to the minimum rights, with approval for consequential actions. Trusting it because it is internal, or because it passed testing once, ignores manipulation, and sharing a privileged account removes accountability.
Want more questions like this? Full AAISM practice tests →
This lesson covers subtopic 3A of Domain 3, AI Technologies and Controls (38%); the recap is at technologies and controls explained.