"Agent" is one word covering five different architectures. The five share a model at the center and one surface an attacker can write into, and past that they fail in five different places. Security guidance calibrated to the word protects none of them well.
On the morning of April 16, 1947, the Grandcamp, a former Liberty ship owned by the French Government, sat at a pier in Texas City, Texas, loading roughly 2,300 tons of ammonium nitrate fertilizer bound for postwar Europe. The paper bags read "Fertilizer (Ammonium Nitrate) 32.5% Nitrogen." They carried no hazard warning, because the federal transport regulator of the era gave the material no classification "other than as fertilizer," and the one label the rules might have demanded, oxidizing material, was waived for bags under 200 pounds.
Every decision on that pier followed the word on the bags instead of the chemistry inside them. Longshoremen smoked on the job, and Justice Robert Jackson, dissenting in the litigation that followed, treated that smoking as predictable rather than reckless, given sacks that carried no warning at all. When stevedores found smoke in a hold that morning, the investigation records that "someone gave orders not to apply water, as the cargo would be damaged." The hatches were closed and steam was piped in, a method that fights fire by starving it of air. Ammonium nitrate supplies its own oxygen. At 9:12 a.m. the ship detonated. A second ship carrying the same material exploded about sixteen hours later. At least 581 people died.
I review system intakes for a living, the forms a team files when a new system first reaches security review, and the word "agent" is doing the same work on those forms today that "fertilizer" did on the paper sacks. A label describes what something is for. A classification describes what it can do. On that pier, every control was calibrated to the label, and the label was true. It just wasn't the information that mattered.
The fire investigation published its finding within two weeks. "The false security engendered in the handling of ammonium nitrate which was such a major factor in this disaster was caused by the improper labeling of the paper bags."
The correction arrived as reclassification. Ammonium nitrate is a Division 5.1 oxidizer today, the placard rides with the cargo, and the federal vessel-stowage rule (49 CFR 176.410) names the compound specifically. Fire hoses are connected and tested before loading begins. A fire watch stands in the hold. Smoking is confined to designated areas away from the material. Every requirement keys off the hazard class, because controls calibrated to a label protect the product, and controls calibrated to the class protect the people.
Chapter 1 stated this book's thesis. Safety is not a property of models. It emerges from interaction, and no single layer can guarantee it, so that chapter drew the agentic stack as three layers: context, model, and execution. Interaction patterns differ by agent type, so the layered controls must differ too. The three layers say where controls live. The type says which controls each layer needs.
The industry's definition wars will not supply the missing vocabulary, because they were fought over a different question, whether a given system qualifies as an agent at all. In September 2025, Simon Willison argued that fight had settled, and the agreed definition takes one sentence. An agent runs tools in a loop to achieve a goal. None of the security guidance I've read sorts agents by which kind, by where the failure lands. This chapter answers that question with five architecture types, two more axes, and one sentence your team should be able to complete before it secures anything.
The Monolithic "Agent" Problem
The major agent-security frameworks each answer a real question, and none of them answers which kind of agent you are securing. The Open Worldwide Application Security Project (OWASP) publishes a Top 10 for agentic applications, a threat taxonomy that tells you what can go wrong. The Cloud Security Alliance's MAESTRO framework (Multi-Agent Environment, Security, Threat, Risk, and Outcome) maps seven architectural layers, which tells you where things go wrong. Forrester's AEGIS framework (Agentic AI Enterprise Guardrails for Information Security) defines six enterprise governance domains, which tells you what to build. All three also treat "the agent" as a single category.
None of the three is wrong to simplify, and the simplification still carries a concrete cost. Generic controls under-protect the dominant threat surface and over-constrain everything else. Sandbox a research agent that only reads, and you've paid real isolation costs against a risk that was never about execution. Output-filter a coding agent, and the filter inspects the conversation while the actual risk ships in the artifact, the code or configuration the agent hands off. Both controls are legitimate. Both are calibrated to the label instead of the class.
Book 1 ran on one discipline above the rest. Understand a system before you attempt to govern it. "Secure the agent" is a mandate you can neither test nor fail until you can name the kind of agent in front of you. You cannot secure what you have not classified.
The Five Architecture Types
The taxonomy that follows is this book's framework, not an industry standard. I am planting it on purpose, because the frameworks above answer other questions, and every chapter that follows needs this one answered first. Five architecture types, sorted by what the system is built to do and where its failures land.
| Type | What it is | Example systems | Dominant threat surface | Governance weight |
|---|---|---|---|---|
| Automation | Fixed trigger, fixed task, narrow scope | Scheduled report generation, rule-based data cleanup | Input validation, blast radius of its one task | Low to moderate |
| Orchestration | Delegates goals to tools, services, and other agents | A project-manager agent routing work to specialists | Authority scoping, trust escalation, cascading failure | Very high |
| Coding | Produces artifacts that something else runs | Claude Code, Cursor, GitHub Copilot coding agent | Artifact provenance, review gates, sandboxed execution | Moderate to high |
| Research / Retrieval | Reads and synthesizes external sources | Deep research agents, document Q&A, retrieval pipelines | Source attribution, memory hygiene, indirect injection | Moderate, higher when the sources are sensitive |
| Interactive / Conversational | Direct dialogue with end users | Customer service bots, in-app copilots | Personal data handling, social engineering, output filtering | High when regulated data is in scope |
This table is the placard moment. The class starts carrying the information the label dropped. Governance weight, the last column, is where that information turns into budget. It sets how deep the review goes, which approval tier the deployment needs, and how much of the control budget the agent draws. Two rows carry a condition, because the data an agent handles can raise the weight without changing the type.
Automation agents are the narrowest of the five. A fixed trigger fires a fixed task inside a narrow scope, the scheduled report generation, the rule-based data cleanup. The model supplies judgment inside the task, never discretion about which task to run. The dominant surface is input validation on whatever fires the trigger, plus the blast radius of the one thing the agent does, how much breaks when that one task goes wrong. Governance weight is low to moderate and concentrates at the inputs and outputs. Teams underrate this row because it looks harmless, then wire its one task into systems that are not.
Orchestration agents delegate. They hold a goal, break it into work, and route the work to tools, services, and other agents, the way a project-manager agent routes tasks to specialists. The dominant surface is authority itself. Scope what the orchestrator may delegate, watch for trust escalating as work hops between agents, and contain the cascade when one delegate fails. Privilege compounds here, which is why the governance weight is the highest of the five. Book 1 treated orchestration as a design discipline. This book treats it as the place where one bad routing decision, if delegation is left unscoped, can hand a delegate everyone's permissions.
Coding agents produce changes that outlive the session that made them. Claude Code, Cursor, and GitHub's Copilot coding agent all sit in this row, handing off source code, configuration, and infrastructure-as-code (the definition files that build servers) for something else to run after the session ends. A hostile or careless change stays live long after anyone was watching. That puts the dominant surface at artifact provenance (where a change came from and who touched it), the review gates a change must clear before it merges into the shared codebase, and the sandbox around anything executed along the way. Governance weight is moderate to high, concentrated where the artifact leaves the agent's hands. Once the sandbox holds, the dominant risk is not the agent going rogue mid-session. It is the quiet merge nobody re-read.
Research and retrieval agents read and synthesize external sources. Deep research agents, document question-and-answer systems, and retrieval-augmented generation (RAG) pipelines, where the agent looks material up before answering, all sit in this row. These systems mostly read, so the risk is epistemic, a risk to what your organization believes rather than what it does. The dominant surface is the supply chain of belief: source attribution, the hygiene of what enters memory, and indirect injection, hostile instructions hiding inside the documents the agent retrieves. The reading cuts both ways, because an agent with access to a sensitive body of documents can be induced to repeat what it read, which makes the row an outbound leak path as well. Governance weight is moderate, and the failure mode is easy to miss, compounding downstream when other systems act on a contaminated answer.
Interactive agents are the row where governance weight swings hardest. A financial services bot and a hobby-project bot share the architecture, direct dialogue with an end user. They do not share the weight. The weight runs high the instant regulated content or personal data (personally identifiable information, or PII) enters the conversation. The dominant surface is the human boundary. Personal data flows in and out. Social engineering runs both ways, aimed at the agent through the user and at the user through the agent. Output filtering decides what the system may say. The customer service bot and the copilot embedded in an application live in this row, and the weight follows what flows through the conversation.
Each type has one threat surface that dominates the rest, and that one fact is what makes the taxonomy usable. Name the type and you know where the control budget goes. The name also says which of the seven posture domains leads, the seven surfaces Chapter 6 builds the rest of this book's assessment around. For an interactive agent, Input Posture leads, because the conversation itself is the attack surface, and the other six domains re-weight as the type changes.
Two More Axes: Domain and Lifetime
Deployment domain is the first, the business problem the agent serves: healthcare, finance, legal, security operations, infrastructure. The domain axis moves independently of the architecture axis. A financial-domain agent can be any of the five types, an automation agent reconciling ledgers or an interactive agent working customer disputes. A coding agent stays a coding agent whatever it builds, healthcare software this quarter and trading systems the next. The domain decides who gets hurt when the agent fails, which regulator shows up afterward, and whether the action can be undone.
The chemical regime drew the same line long ago. Fertilizer-grade and technical-grade ammonium nitrate are chemically identical in a fire, and the grade names only say which market each is sold into. Domain is the grade name. Architecture is the class. Chapter 15 takes up the domain axis in depth, where committing a change means something different in each domain.
Lifetime is the axis Book 1 discovered from the build side. Book 1's Chapter 16, the factory chapter, split agent products into persistent agents that retain context across tasks and ephemeral subagents that take one task and then discard everything. That build-time split becomes a security axis here, and the vocabulary shifts with it, so what Book 1 called persistent this book calls permanent. A permanent agent is a supervisor with state across sessions. An ephemeral agent spawns, executes, and vanishes.
Permanent agents inherit the traditional identity stack, because the patterns from forty years of identity and access management (IAM) transfer to them almost unchanged. Give the agent a unique workload identity, an identity issued to the software itself rather than borrowed from a human account. Issue short-lived credentials that rotate automatically. Key the audit trail to a stable identifier. Six identity engineers, from Defakto, AWS, Zscaler, Okta, OpenAI, and Ping, have submitted an Internet-Draft on exactly this framing to the Internet Engineering Task Force (IETF), the internet standards body. Agents are workloads, and the identity machinery already built for service workloads fits them.
Ephemeral agents break that machinery, because there is no stable identifier to key anything to and no standing credential to rotate. They force the controls upstream to the spawn event. Identity and tool scope are granted when the worker is created. The parent's execution trace becomes the durable audit record, because the worker is gone by the time anyone asks what it did.
The platforms are already built for this. Claude Code's subagents inherit the parent's tools unless the configuration restricts them, so the spawn configuration is the control point. Even whether a worker may create workers of its own is decided there. On AWS, a session policy layered over the agent's standing role reaches the same effect. Each tool call runs only with the permissions both allow.
Most orchestration agents are permanent. Most spawned workers are ephemeral. Coding agents run either way depending on whether they hold session state, and composite systems run both at once, a permanent supervisor coordinating ephemeral workers. Chapter 17 follows the spawn trees those workers create and what propagates down them, and Chapter 13 builds the observability that survives a subagent's death.
Every agent you run sits at one intersection: an architecture type, a deployment domain, a lifetime. Fill in the three for one system and you get a coding agent, deployed in healthcare, running as ephemeral, and each coordinate changes which controls you check first.
Composite Agents: Types Stack, Surfaces Multiply
Real systems refuse to stay in one row of the table. Picture a hypothetical product a team might ship tomorrow, a "security review agent" that routes findings to specialist agents, generates remediation pull requests (proposed code changes queued for a human to review), and summarizes advisories from the public Common Vulnerabilities and Exposures (CVE) catalog. Hold it against the taxonomy and the single product name dissolves.
Routing findings is orchestration. Generating pull requests is coding. Summarizing advisories is research and retrieval. Three types, three threat models, one name on the intake form. Govern it as one thing and you're governing all three without knowing it.
Composition multiplies the threat surface rather than adding to it. That framing is mine. A poisoned advisory summary is a research-surface problem, an agent believing something false. The moment the system routes work based on that summary, the false belief becomes an orchestration-surface problem, authority pointed at the wrong target. When the routed work merges as a pull request, it lands as a coding-surface problem, a hostile artifact inside the codebase. One injection crossed two type boundaries and picked up authority at every hop.
Classify by the capabilities present, never by the product name. Type the components first, then govern the composition as the stack it actually is. The same rule covers the agent that fits no row cleanly, an agent that works a desktop through its screen, say. Type it by the capabilities it does have, and where two rows come close, govern at the heavier weight of the two.
Who Answers When It Goes Wrong
Typing an agent also settles who answers for it. On April 9, 2026, Anthropic published "Trustworthy agents in practice" and drew an agent as four layers: the model, a harness, the tools it can use, and the environment it runs in. That harness is the narrow kind, the instructions and guardrails the model operates under. Book 1 used the same word for the whole system built around a model, so read it narrowly here. Set against the three layers this book drew in Chapter 1, the model is the model, the harness sits in the context layer, and the tools and the environment are the execution layer.
On April 11, Maor Kuriel asked on LinkedIn, "Who Is Responsible When an AI Agent Goes Wrong?" The discussion that followed seeded this chapter, because my answer to his question kept coming out the same way. It depends on the kind of agent.
Name the type and "it depends" gets specific, with a weighting that is mine, laid over those four layers. For an interactive agent facing customers, the harness carries the most weight, because the policies, approvals, and rules for what the system may say all live there. For a coding agent, the environment carries it, plus the review gates around the artifact, the one control that sits outside all four layers. For an orchestration agent, the weight sits on the tools and the delegation boundaries between them.
Anthropic names the layers and does not say who owns them. I put an owner on each. Whoever wrote the harness answers for the harness, whoever runs the environment answers for the environment, whoever wired the tools answers for the tools, and the model stays with the vendor that trained it. Asked about the category, the responsibility question stays philosophical. Asked about a typed agent, the same question produces an answer with owners in it.
Underneath sits a harder accountability question, which human is bound to the outcome when every layer held and the loss happened anyway. That one belongs to Chapter 16, which takes up the accountability spectrum and how a named human gets bound to each consequential action an agent takes.
Name It Before You Assess It
Every security assessment of an agentic system should start with one sentence the team completes in agreement.
"This is a [type] agent, deployed in [domain], running as [permanent or ephemeral]."
The sentence is the placard. In the chemical regime, the hazard class determines the placard, and the placard determines the handling rules. In agentic systems, the type determines the threat model, and the threat model determines the control set. Classification is a control decision, because every downstream rule inherits from it.
When a team cannot complete the sentence, or completes it three different ways, that disagreement is finding number one. The security review agent from the composite section fails the sentence on its face. It is three types wearing one name, and the team that tries to fill in the blanks discovers that before the assessment starts instead of after the incident. My own reviews now open by forcing this sentence onto the intake form before any control gets discussed. Re-run the sentence whenever the agent gains a tool or a data source.
Chapter 6 opens the posture work with a Three-Question Triage covering privileges, extensibility, and memory governance, and all three questions assume you can already say which agent you mean.
The Slide the Vocabulary Prevents
The incident record I track skews heavily toward coding agents, and so does most published guidance, whether or not it says so. Without the taxonomy, practitioners and vendors carry coding-agent lessons over into "agent security" and apply them to research agents and customer-facing systems they were never derived from. This book narrows the same way on purpose. Part IV is about coding agents and software delivery. This chapter says so up front. The vocabulary is what keeps this book, and your program, from making that slide.
From Vocabulary to Attack Surface
You can now name what you're securing, and the name carries real information: a type with a dominant threat surface, a domain with consequences attached, a lifetime with an identity model. Naming is not protection. It is the prerequisite for protection that fits.
Whatever kind of agent reads a document, that document lands in a context window, the model's working memory for the task, and an attacker who can write into the window doesn't care what the intake form says. Chapter 3 is about the one surface every row of the table shares: injection, pollution, and the ways data leaks back out, across a perimeter that shifts with every document the agent takes in.
Classification regimes tend to be written after the incident that proves them necessary. Texas City's placards arrived that way. This field is still early enough to write the regime first, and the one-sentence placard above is where it starts.