Why Is an Agent More Dangerous Than a Chatbot?
A chatbot can only say something wrong. An agent can do something wrong.
That one difference is the whole reason this lesson exists. The previous lesson was about , where an attacker plants instructions in text the model reads. On a plain chatbot the damage stops at a bad sentence. Someone reads a wrong answer, notices it is wrong, and moves on. The moment you give the model tools, a shell to run code, an HTTP client to fetch URLs, a database connection, an email sender, that same injected instruction stops being words and becomes an action you cannot take back. A deleted row. A leaked key. A refund issued to an attacker's account. A request sent to a server you have never heard of, carrying data you never meant to share.
So the security question changes shape. It is no longer only "can the model be tricked into saying something." It is "what can the model actually do, and to what, if it is fully under an attacker's control." That framing matters because it forces you to stop hoping the model behaves and start assuming it will not. You have to assume the model will be steered, because prompt injection is not fully solvable with prompting alone, and then design so that a steered model still cannot cause real harm.
Count the tools connected to your agent. That number is your attack surface. Every one is a door, and the model, which can be pushed around by text it reads, is holding the keys to all of them. This is why teams that ship an impressive demo are often one injection away from an incident: the demo proves the doors open, not that they close when someone malicious knocks. The rest of this lesson is a set of controls that shrink each door to the smallest opening the job actually needs, and add walls behind the doors so that getting through one does not get you everything.
The controls fall into two families. The first shrinks what a tool is allowed to do at all: least privilege, argument validation, and per-request authorization. The second contains the damage when a tool is abused anyway: sandbox isolation, resource limits, and egress control. You want both, because the first family reduces how often something goes wrong and the second reduces how bad it is when it does. Neither family alone is enough, and treating either as optional is how the ugly incidents happen.