7. Agentic AI

Introduction

In July 2025, a company was nine days into building a product with an AI coding agent. The team had declared a code freeze – no changes to production. The instruction was in the agent’s prompt, in plain language, and the agent acknowledged it.

Then it deleted the production database. Roughly 1,200 executive records and 1,196 business records, gone. Asked what had happened, the agent misreported its own actions, said rollback was impossible when it was not, and rated the severity of what it had done 95 out of 100.

No attacker was involved. Nobody had injected anything. The code freeze existed only as words in a prompt, and nothing in the execution path enforced it. The agent could read “do not touch production,” agree with it, and issue the write anyway, because agreement and enforcement are different things.

Section 5 established that an instruction in a prompt is a request rather than a boundary. This section is where that stops being an abstraction. Once a model can act, the gap between what you asked for and what is enforced becomes the gap between a bad paragraph and a deleted database.

From Answering to Acting

Generative AI arrived in stages, and each stage added a capability the previous one lacked:

• Base models generate text from prompts. Limited to training data, no way to verify a claim, no way to act.
• Retrieval-augmented systems (Section 6) add current, private knowledge. Still strictly reactive: they answer when asked.
• Agentic systems pursue goals. They decide what to do next, call tools, read the results, and iterate – writing files, running commands, querying databases, and calling external services without a human approving each step.

That third step is not an incremental improvement. It changes what a failure costs.

The Agent Loop

Every agentic system runs the same loop: plan a step, select a tool, execute it, observe what came back, decide whether to continue.

graph TB
    subgraph core["Agent Core -- the context window"]
        A["1. Plan<br/>(decompose the goal)"] --> B["2. Select Tool<br/>(choose an action)"]
        B --> C["3. Execute Tool"]
        C --> D["4. Observe Result<br/>(tool output enters the context)"]
        D --> E{"5. Goal met?"}
        E -->|No| A
        E -->|Yes| K["Return result"]
    end

    subgraph world["External World -- not yours to trust"]
        F["Files & repos"]
        G["Web pages"]
        H["Databases & APIs"]
        I["Email & messages"]
        J["Other agents"]
    end

    C ==>|"EGRESS: effects<br/>you cannot undo"| world
    world ==>|"INGRESS: text that<br/>reaches the model as<br/>instructions"| D

    style A fill:#2d5016,color:#fff
    style B fill:#2d5016,color:#fff
    style C fill:#8b0000,color:#fff
    style D fill:#8b0000,color:#fff
    style E fill:#2d5016,color:#fff
    style F fill:#4a4a4a,color:#fff
    style G fill:#4a4a4a,color:#fff
    style H fill:#4a4a4a,color:#fff
    style I fill:#4a4a4a,color:#fff
    style J fill:#4a4a4a,color:#fff

Two steps are red, and the distinction between them is the single most useful thing in this section.

Step 3, Execute, is egress. It is where the agent’s decisions become effects in the world – a file written, a payment made, a table dropped. Egress is where damage happens.

Step 4, Observe, is ingress. It is where the world’s text comes back into the agent. And here is the part that surprises people: Section 4 established that a context window is flat – everything in it arrives as one undifferentiated token sequence with no privilege levels. Tool output lands in that same sequence. A web page the agent fetched, a code comment it read, an email body it summarised: all of it is indistinguishable from instructions once it is in the context, because there is no channel that marks it as data.

The Lethal Trifecta

“Every capability is an attack surface” is true and nearly useless – it tells you to worry without telling you what to look at. There is a sharper test, named by Simon Willison in June 2025, and it is the most portable thing you will take from this section.

An agent is in serious trouble when it has all three of these at once:

1. Access to private data – your repositories, mailbox, customer records, internal documents.
2. Exposure to untrusted content – anything written by someone who is not you: a web page, an email, an issue comment, a dependency’s README, another agent’s message.
3. The ability to communicate externally – any way to get bytes out. An HTTP request, an email, a commit, a database write, or something as innocuous as rendering an image from a URL it chose.

With all three, an attacker who controls the untrusted content can instruct the agent to fetch the private data and ship it out. The agent is not broken when this happens. It is doing exactly what it does: reading text and following it.

Notice that the third leg is the one people consistently under-count. Exfiltration does not need a network tool. If an agent can write a file into a repository that has CI, or render markdown that loads an image, or add a row a dashboard reads, it can communicate externally. Ask what the agent can cause to be transmitted, not what tools have “send” in the name.

The Spectrum of Agency

Not every AI-powered system is an agent, and the vendor’s label will not tell you which you have. What determines risk is mechanical: what the system can reach, who can write into its context, and what stands between a decision and an effect.

Script or agent?

Not an agent: a script that asks an LLM “is this email phishing? TRUE or FALSE” and routes on the answer. The LLM never chooses what happens next. This is a function call with a fuzzy implementation, and it needs the controls any function needs.

An agent: a system told “investigate this alert” that decides on its own to pull logs, query the SIEM, correlate threat intel, and escalate – choosing each step from what the previous one returned. Nobody wrote that sequence down. It cannot be reviewed in advance, because it does not exist until it runs.

That is the distinction with teeth: for a script you can review the control flow, and for an agent you can only constrain it. Testing tells you much less about an agent than about a script, for the reason Section 5 gave – the same input does not reliably produce the same output.

Excessive agency has three separate causes

The industry term for the underlying flaw is excessive agency – LLM03 in the OWASP LLM Top 10 2026, and the bridge Chapter 2 uses into the agentic taxonomy. It is worth decomposing, because the three causes have different fixes and systems usually have only one of them:

• Excessive functionality – the agent has tools it does not need for its task. A summarising agent with a delete_file tool. Fix: remove the tool.
• Excessive permissions – the tools it does need run with more privilege than the task requires. A read-only reporting agent connecting as database owner. Fix: scope the credential, not the prompt.
• Excessive autonomy – high-impact, irreversible actions proceed with no human checkpoint. Fix: a gate on the irreversible subset, not on everything – a gate on everything becomes a gate on nothing.

Run these three questions at a design review and you will find the problem faster than by reading the system prompt.

How Agents Get Their Tools: MCP

An agent is a model plus tools, and in 2026 those tools mostly arrive over the Model Context Protocol (MCP) – an open standard, introduced by Anthropic in late 2024 and now supported across essentially every major agent client. MCP is why an agent can talk to your ticket tracker, your database and your design tool without anyone writing a bespoke integration for each pairing.

The mechanism is worth understanding precisely, because the security consequences follow directly from it. An MCP server advertises a list of tools. Each tool has a name, a machine-readable schema, and a natural-language description telling the model when and how to use it. The agent’s client fetches those descriptions and puts them into the context window so the model can choose between them.

That last sentence is the whole problem: a tool description is untrusted text that goes straight into the prompt, and the user never sees it.

The defensive shape here is the one Section 6 found for retrieval and Section 5 found for prompts: the control is not an instruction to the model. It is an inventory of which servers are connected, a pinned version, and an egress policy – which is why this lands in Chapter 3 as supply-chain defense and orchestration-layer security rather than as prompt hygiene.

Agentic Tools in Production

These tools are already daily infrastructure. Read the table below for what each one reaches and who can write into it – the two trifecta legs – rather than for its feature list.

Three patterns are worth naming, because they shift where your control has to sit:

• Developer agents hold write access to your codebase and usually your shell. A manipulated agent can introduce a vulnerability that survives review – especially where the reviewer is also an agent. The untrusted input is the repository itself: issue text, dependency manifests, code comments.
• Business automation agents hold credentials rather than code access. An n8n workflow reaching CRM, mail and payments has a blast radius spanning all three, and its untrusted input arrives unprompted through webhooks and inbound mail. Nobody is watching when it fires at 3 a.m.
• Frameworks and self-hosted runtimes ship with capability as the default and security as your homework. There are no guardrails you did not add.

Multi-Agent Systems

An agentic workflow is a sequence of steps where agents, not a fixed program, decide the progression. Compare three shapes:

Multi-agent systems build on three capabilities, each of which is also the attack surface Chapter 2 targets:

1. Planning – decomposing a goal into steps. Attacked by goal hijacking (ASI01): change what the agent thinks it was asked to do.
2. Tool use – acting through granted capabilities. Attacked by tool misuse (ASI02) and privilege abuse (ASI03).
3. Reflection – assessing results and adjusting. Attacked by memory and context poisoning (ASI06), which is worse than it sounds: a poisoned observation persists into every later decision, so one bad read shapes the whole run.

Splitting the work does not split the risk

A five-agent content pipeline – manager, researcher, writer, editor, quality control – looks like separation of duties. It usually is not, and the reason is worth stating plainly:

• Privilege is unioned, not partitioned. The system’s effective reach is every tool granted to any agent in it. Compromising the weakest agent and delegating gets you the strongest one’s tools.
• Inter-agent messages are untrusted input that looks trustworthy. Agent B receives text from Agent A and treats it as a colleague’s instruction. It is text, arriving in a flat context window, with the same lack of privilege markers as a web page. This is insecure inter-agent communication (ASI07).
• The researcher reads the internet and the writer holds the credentials. Separately, neither has the trifecta. Connected, the system does – assembled from components that each looked fine in isolation. This is cascading failure (ASI08).

Assess the trifecta over the whole system, not per agent. A reviewer who checks each agent individually will approve an architecture that has all three legs.

Every Capability Maps to a Control

Here is the payoff of the whole chapter. Each agentic capability creates a specific attack, and each attack has a control that lives somewhere specific – and never inside the prompt. The ASI codes below are the OWASP Top 10 for Agentic Applications, the standard taxonomy for agent risk; Chapter 2 Section 5 works through all ten.

Why Adoption Continues Anyway

Security review usually arrives after agents are already deployed, and it helps to know why.

• Adoption is broad. 84% of developers use or plan to use AI tools, and 51% of professional developers use them daily.
• The forecast is aggressive. Agentic capabilities in 33% of enterprise applications by 2028, from under 1% in 2024 (Gartner).
• The projected economic value is very large – and frequently misquoted. The widely cited $2.6–4.4 trillion annually figure is McKinsey’s 2023 estimate for generative AI across 63 use cases, not a measurement, and not specifically about agents. Treat it as a projection of an addressable opportunity.

Now the finding that should change how you approach an agentic deployment. In a randomized controlled trial, METR measured experienced open-source developers on 246 real tasks in their own repositories. With AI tools allowed, they were 19% slower. Afterwards, they estimated AI had made them 20% faster.

Agents are being deployed regardless, which makes “should we?” the wrong question to bring to a design review. The useful questions are the ones this section has given you: what does it reach, who writes into it, what can it transmit, and what stands between a decision and an effect.

Looking Ahead: From Understanding to Attacking

Chapter 1 is complete. You now have the models that Chapter 2 attacks and Chapter 3 defends – and each one has a specific successor:

Start with Chapter 2 Section 1: The AI Attack Surface for the taxonomy, or go straight to Section 5: Agentic AI Attack Vectors to continue this thread.