---
title: "AI Agent Architecture Security: A Layer-by-Layer Reference"
description: "A security reference for agent architecture, layer by layer: the model, context and memory, the tool layer, identity and orchestration, with the trust boundary that belongs to each."
author: "Renn Calloway"
category: "Defensive Architecture & Security Controls"
date: 2026-10-16T07:15:00.889Z
canonical: "https://agenticcyber.co/blog/ai-agent-architecture-a-security-reference-for-builders"
---

# AI Agent Architecture Security: A Layer-by-Layer Reference

![town, buildings, houses](https://cdn.pixabay.com/photo/2017/06/22/11/54/town-2430571_1280.jpg?w=1200&q=75)

> A security reference for agent architecture, layer by layer: the model, context and memory, the tool layer, identity and orchestration, with the trust boundary that belongs to each.

A builder's architecture diagram and a reviewer's architecture diagram are not the same drawing. The builder's version puts a model in the middle, wraps a loop around it, and labels two boxes tools and memory. The reviewer needs those boxes plus three overlays: where text the business does not control arrives, where credentials get presented, and where something other than the model is allowed to refuse.

This reference walks an agent in the order a pre-launch review should take it: the model, context and memory, the tool layer, identity, and orchestration. Each section names the trust boundary that belongs to that layer, what crosses it, and what does the enforcing once the model is wrong. It is a design aid rather than a product comparison, and it assumes you are reading a system that somebody intends to ship this quarter.

## What makes an agent diagram reviewable

Three labels turn a developer sketch into something a security reviewer can work with. Mark every arrow carrying text from outside your trust perimeter. Mark every arrow where a credential is presented to another system. Mark every point where a deterministic check or a person can halt the run. A drawing with all three answers the only question a launch review really has: can hostile text reach authority without passing a stop?

Anthropic's engineering team frames the underlying choice as one of predictability. Where the order of steps can be fixed in code, the source tells you what the system will do. Where it cannot, the team argues that "agents are the better option when flexibility and model-driven decision-making are needed at scale" ([Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)). Take that trade and a consequence follows for the reviewer: your code has stopped describing what will happen and now only describes what cannot.

## Why component reviews miss the finding

An agent fuses three things most security teams keep in separate rooms. A natural-language interpreter that cannot tell an instruction from a piece of data. A set of credentials. A loop that proceeds without anybody watching. Each is tractable in isolation. Assembled, the least trustworthy input in the system sits directly upstream of the most privileged action available to it.

Reviews stall because they grade parts. A model is neither safe nor unsafe; a tool is neither safe nor unsafe. The risk lives in the join between them. Walking layers works better because each layer owns exactly one boundary, and a boundary is something you can poke. Asking whether the model is secure produces a discussion. Asking what enforces the limit when the model is manipulated produces a ticket with an owner.

## Layer one: the model and its instruction stream

The model takes the system prompt, the conversation so far, retrieved documents and tool output as one undifferentiated run of tokens. **The boundary at this layer is nominal.** Nothing inside that stream distinguishes your instructions from content an attacker contributed, which is why the system prompt deserves to be read as a strong default and never as a policy engine. Keep secrets out of it. Keep authorisation rules out of it. Version it and record the version with each run, because a prompt edit is a behaviour change and your logs should be able to account for one.

Prompt-level defences still earn a place. They shift the odds, they cost almost nothing, and they catch the lazy attempts. They are a filter rather than a wall, and a design that treats them as a wall will fail at this layer with no telemetry to explain why.

## Layer two: context and memory

Retrieval stores, scratchpads and long-lived memory govern what the model reads on its next run, which makes this the layer where text injected today becomes an input next week. **The boundary is the write path into the store, not the read path out of it.** Tag each stored item with its origin and a trust label, then carry that label through retrieval so a later step can treat a scraped page differently from a countersigned contract. Partition memory per tenant and per task, and expire it deliberately rather than letting it accumulate. One tenant's content surfacing in another tenant's retrieval is already a data incident, whatever the model then chooses to do with it.

Summarisation deserves separate attention. Each compaction pass rewrites untrusted text into something that reads like the agent's own conclusion, and trust labels are exactly what tends to be dropped in the rewrite. If the pipeline summarises, make the summary inherit the lowest trust label among its inputs.

## Layer three: the tool layer

Tools are where a token prediction turns into a side effect. For each one, write down what it reads, what it mutates, which credential it presents, and whether the effect can be reversed. Prefer a narrow tool that drafts a reply over a broad one that runs arbitrary statements. **The boundary is the tool schema and the validation sitting behind it,** which means a tool accepting a free-text command has effectively declined to have a boundary at all. Anthropic's team puts unusual weight here, recommending that builders "carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing" ([Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)). OWASP's entry on Excessive Agency points the same direction, listing "Minimize extension functionality", "Avoid open-ended extensions" and "Complete mediation" among its mitigations ([OWASP LLM06:2025](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)). Where a broad capability genuinely has to exist, isolate its execution: the piece on [isolating agent tool calls](/sandboxing-ai-agent-tool-calls-an-isolation-architecture) sets out the available patterns.

## Layer four: identity

An agent running on a developer's token or a shared service account has no identity, and neither your authorisation decisions nor your audit trail can reconstruct one afterwards. Issue every agent its own principal, with short-lived credentials scoped to the task in front of it. Where an action is taken on behalf of a named person, carry that person's authority explicitly instead of letting the agent act as itself with wider rights, which is the confused deputy problem in new clothing. **The boundary is the token: its audience, its scopes and its lifetime.** Everything enforced at this layer is enforced by systems that do not read prompts, which is the whole reason the migration effort is worth budgeting. The recurring failure patterns are collected in our guide to [non-human identity for agents](/non-human-identity-security-for-ai-agents).

## Layer five: orchestration

The loop decides whether the model gets called again, and it is the only layer that can end a run. Cap iterations, cap tool calls, cap spend per task, so that a malfunction terminates as a bounded failure instead of an invoice. OWASP describes applications that permit "excessive and uncontrolled inferences, leading to risks such as denial of service (DoS), economic losses, model theft, and service degradation", and names "Denial of Wallet (DoW)" as a risk in its own right ([OWASP LLM10:2025](https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/)). Put a gate in front of anything irreversible, which Anthropic's team describes as a design option rather than a compromise: "Agents can then pause for human feedback at checkpoints or when encountering blockers" ([Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)). **The boundary is the stop: who may halt a run, how quickly, and what state is left behind when they do.** Decide that at design time rather than during an incident, and write the run log somewhere the agent's own credentials cannot reach. The containment questions are worked through in the piece on [stop, containment and rollback](/ai-agent-kill-switch-designing-stop-containment-and-rollback).

Multiple agents multiply this layer rather than replacing it. Every message between agents is a fresh untrusted channel and a fresh identity question, so a peer's output deserves the same label a web page gets. Where one agent can start another, the caps have to compose, or a step limit per agent becomes no limit at all across the fleet.

## Turning the layers into findings

Walk the five layers with the system owner and ask one question at each. Which inputs can a stranger write to? What trust label does a retrieved item carry by the time it reaches the model? Which credential sits behind each tool? Whose authority is on the token? What ends the run, and who can trigger it? A vague answer is the finding, and most of these are fixable without touching the model at all, which is the part that tends to calm a nervous launch committee. Routing the findings into a structured method stops them becoming a pile of opinions: the work on [where STRIDE falls short for agentic systems](/threat-modeling-agentic-ai-stride-gaps) is a reasonable starting point.

## Where the Published Control Work Is Heading

NIST is writing control overlays rather than new frameworks. Its [Control Overlays for Securing AI Systems project](https://csrc.nist.gov/projects/cosais) applies the SP 800-53 catalogue to five named use cases, and the detail that matters for a builder is that single-agent systems and multi-agent systems are separate cases on that list, alongside generative AI assistants, predictive AI and controls for AI developers. The concept paper is dated 14 August 2025, an annotated outline for the predictive AI case followed on 8 January 2026, and no initial public draft had appeared when this was written. Design consequence: record which of the five cases your system is, in the same document as the diagram, because the control set that eventually applies will be selected by that label.

The risk vocabulary has also caught up with agents specifically. The OWASP GenAI Security Project published [the Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications/) on 9 December 2025, covering risks that arise from autonomy, delegation, memory and agents coordinating with each other, with the numbered categories inside the downloadable document. Read it against layers two and five rather than layer one, whose failures the older application-oriented list already names well.

One more item belongs in layer four, because the specification underneath it moved. The current revision of the Model Context Protocol, [in its authorization section](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), requires a server to validate that an access token was issued specifically for it as the intended audience, states that a server must only accept tokens valid for its own resources, and says plainly that it must not accept or transit any other token. On the client side it requires the resource indicator parameter from [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) in both the authorization request and the token request, and requires clients to send it whether or not the authorization server supports it. If any tool at layer three reaches an MCP server, that is the normative text your identity boundary is measured against. [The audience and confused-deputy problem](/mcp-server-authorization-token-audience-confused-deputy) is worked through separately.

## Stay at One Agent Until You Can Say Why Not

The position behind that short multi-agent paragraph is stronger than the paragraph admits: keep the agent count at one until somebody states a requirement a single agent with more tools cannot meet. Most multi-agent designs arriving at review are not there for a constraint. They are there because the framework's examples read that way, or because named roles present better to a stakeholder than one box and a tool list.

The cost is not abstract. Every additional agent adds an untrusted channel, because a peer's output is model-shaped text and deserves the same label a scraped page gets. It adds an identity question, because the second agent either borrows the first one's authority, which collapses your layer four, or needs a principal and a scope of its own. And it adds a cap that has to compose, because a per-agent step limit is no limit at all once one agent can start another. Three layers get harder for each box you draw, and none of them gets easier.

The outside evidence agrees. The December 2025 agent risk list adds categories for delegation and for agents coordinating with each other, which says these are distinct failure modes rather than more of the same, and NIST is writing single-agent and multi-agent overlays as separate control sets rather than one with an appendix.

Isolation is the exception to this. Where one component genuinely has to run at a different trust level, in another tenant, or with credentials the rest of the system must never hold, two agents with two principals are safer than one agent holding both sets of keys, and the extra channel is a price worth paying for a boundary you can enforce. That is a real requirement, it is rarer than the diagrams suggest, and it is the sentence a reviewer should ask for before accepting the second box.

## When to bring in an outside reviewer

If the design moves money, reaches production infrastructure, or reads regulated data, commission an independent review before launch rather than after the first surprise. Published guidance, this article included, is technical analysis and not an audit of your system, and it cannot see the connector somebody added last Thursday. Where a compliance obligation is in play, the layer boundaries described here do not map cleanly onto regulatory controls, so get a legal and compliance opinion alongside the technical one.

A well-drawn agent is one where the model being wrong turns out to be boring. The five layers give you the places to make it boring: a stream you never trust, a memory you label, tools narrow enough to describe in a sentence, tokens that are scoped and short-lived, and a loop somebody can stop. How to model trust across a fleet of cooperating agents is still an open argument among practitioners. The boundaries inside a single agent are settled enough to review this week.

## FAQ

### Which layer deserves the most review time on a first pass?

Identity and the tool layer. Both are enforced by systems that never read a prompt, so a fix there survives a model that has been talked into something, and both tend to be the cheapest places to narrow reach before launch.

### Does this reference apply to a vendor agent platform we did not build?

The layers exist whether or not you can see them. What changes is the evidence available: admin config, vendor documentation and audit logs instead of your own code. Anything the vendor will not expose becomes an assurance you have accepted, and it belongs in the review notes as exactly that.

### How does a multi-agent design change the layer map?

It repeats it. Each hop between agents adds an input channel at layer one, a store at layer two and a principal at layer four, and the caps at layer five have to compose across agents or they bound nothing.

### If the system prompt enforces nothing, why bother versioning it?

Because behaviour changes with it. When a run goes wrong, an investigator needs to know which text was in the stream at the time, and a prompt that changed silently makes the timeline unreadable.


---
Source: https://agenticcyber.co/blog/ai-agent-architecture-a-security-reference-for-builders