The Agentic AI Threat Model, MCP Security, and Tool Sandboxing

Everything so far assumed a model that answers. An agent is different: it is given a goal, and it plans, calls tools, observes the results, and calls more tools in a loop until it decides it is done — largely without a human in the loop for each step. That autonomy is the whole value and the whole danger. Every risk from the earlier modules still applies, but now a successful prompt injection doesn't just produce bad text — it produces bad actions, chained. This lesson is the agentic threat model and the controls that contain it.

Excessive agency — the core agentic risk

If you remember one term, make it this. Excessive agency is when an agent has more capability, permission, or autonomy than the task requires — so when something goes wrong (an injection, a misread instruction, a hallucinated plan), the blast radius is large. OWASP calls it out specifically for agentic systems. It has three faces:

Too much functionality. The agent holds tools it doesn't need for the task (a support agent with a database-delete tool "just in case").
Too much permission. The tools it holds are over-scoped (a read task using a read-write admin token — the least-privilege failure from the last module).
Too much autonomy. The agent takes high-impact actions with no human confirmation (issuing refunds, deploying, emailing customers on its own).

Every other agentic threat is basically a way to trigger excessive agency:

Tool misuse. An injection (direct or indirect) steers the agent into calling a legitimate tool for an illegitimate purpose — the confused deputy, now holding real tools.
Runaway loops and cost. The plan-act loop doesn't terminate, or spawns sub-agents recursively — burning money, hammering downstream systems, or amplifying a small error into a large one.
Goal and memory manipulation. Persistent memory or a shared scratchpad gets poisoned so the agent pursues an attacker's objective across steps, or carries a planted instruction from one task into the next.

'Clean up some unused files' — the agent interpreting that a little too literally

The agent loop, with control checkpoints

The way to reason about agentic security is to put controls on the loop itself: at the point it chooses a tool, at the point it acts, and at the boundary of how long it may run.

The agent loop — and where the controls go

Read the loop as an attacker: the dangerous edge is Observe → Plan, where tool output (which may be attacker-controlled, exactly the indirect injection from module 7.2) feeds the next decision. Controls sit at three points — which tool (sandboxing, scope), whether to act (human gate for high-risk), and how long (loop and cost limits).

MCP security and tool sandboxing

Agents reach the world through tools, increasingly via MCP (the Model Context Protocol) — a standard way to expose tools and data to models. MCP is powerful precisely because it makes connecting tools easy, which means the security burden moves to how you scope them:

Each tool is a scoped door. A tool should authenticate with the narrowest credential for its job, tied to the current user where possible (the delegated-token model from 7.3) — never a shared admin credential the whole agent holds.
The agent's authority is the union of its tools. Adding a tool widens the blast radius of every injection. Keep the toolset minimal; audit what each tool can actually do, not what it's "supposed" to do.
Sandbox execution. Tools that run code or touch the filesystem/network run in a confined environment with resource limits, so a misused tool can't reach beyond its box.
Vet third-party MCP servers. A tool server you don't control is untrusted code in your agent's supply chain — it can return malicious content (indirect injection) or exfiltrate what you pass it. Treat it like any other dependency: review, pin, monitor.

The containment mindset

You will not prevent every injection or bad plan, so design for containment: assume the agent will at some point try to do the wrong thing, and make sure it can't do serious harm when it does. Least-privilege tools, a human gate on high-risk actions, and hard loop/cost limits turn a compromised agent from a disaster into a logged, bounded, recoverable event. Autonomy is safe only in proportion to how tightly the actions are scoped.

The GRC throughline

Agentic security produces a specific evidence set: the agent's tool inventory with each tool's scope, the sandboxing configuration, the human-approval workflow and its audit log for high-risk actions, and the loop/cost limits. "The agent operates within least privilege and human oversight" becomes a reviewable design with artifacts. The next lesson adds the retrieval side — RAG access controls — and how red teaming tests all of it before an attacker does.