Prompt Injection 101: 5 Lessons and 5 Exercises for the Week You Inherit an AI Agent

The prompt injection 101 most engineers were taught is the chatbot version.

It has a definition, a list of clever inputs that make a model say things it should not, and a closing section on sanitizing user input. All of it was correct for a text box. Then an agent arrived in your cluster with a tool registry and a service account, the ticket arrived with it, and none of the syllabus describes what you now own.

This is the agent version. Unlearn one thing, learn five, and do five exercises that take about an hour each and leave you with three lists and one test by the end of the week.

Unlearn the Chatbot Syllabus First

Most of the technique catalog you were taught describes attacks on a boundary your agent does not have.

Persona prompts, hypothetical framings, ciphers and character tricks exist to get a model past its refusal training. They are jailbreak lineage, and against an agent that has been asked to read a support ticket and call a lookup tool, there is no refusal in the path to defeat. The attacker wants the agent to call the tool it is already permitted to call. A plain sentence does that, and the fix for a jailbreak belongs to the model vendor anyway.

The chatbot syllabus was right for its era. When the model’s output was the product, a leaked system prompt or an offensive reply was the worst outcome, and tricks that produced them were the threat. Keep the one thing from that syllabus that survives: the mechanism. The model cannot tell an instruction from data. Drop the rest.

Unlearn	Keep or replace with
Role-play and persona attacks	The plain request for an authorized action
System prompt extraction as the main risk	The permission set as the main risk
Encoding and obfuscation tricks	Who can write to the sources the agent reads
“Sanitize user input” as the fix	Scope, credential and network reach as the fix
Prompt filtering as detection	The agent’s own behavior as evidence

Five replacements, five lessons.

Lesson 1: Your Agent Reads Everything as One Document

The system prompt, the user’s request, the retrieved wiki page and the tool’s return value reach the model as one sequence of tokens with no marker saying which part is allowed to give orders.

That is the whole mechanism, and why it cannot be fixed with a parser the way SQL injection was is a separate lesson with its own page. For this week, the operational meaning is enough: any text the agent reads is a candidate instruction, so the first thing to know about your agent is everything it reads.

Exercise 1: list every source. One hour.

1. Open the agent’s configuration and its tool registry. Write down every retrieval source, connector, tool, memory store and upstream agent whose output enters the context.
2. For each, write the path the text takes: retrieved by RAG, returned by a tool, pasted by a user, delivered by another agent, loaded from memory.
3. Add the ones that are not in the config: the system prompt file, the tool descriptions themselves, and any scheduled fetch.

Done looks like a list of sources, usually between six and twenty, each with a path. Most teams find one they did not know about.

Lesson 2: The Damage Is the Permission Set

An injected instruction can only cause what the agent can cause, and what the agent can cause is the product of its tools, its credentials and its network reach.

That is the third part of the definition, the part that turns a strange paragraph into an incident, and it is the part you own. The same sentence in front of a read-only retrieval agent and a write-scoped agent with a service account is two different events. The model is identical. The permission set is the whole difference.

The list you need already exists, in three places nobody has joined: the tool registry, the IAM policy on the service account, and the network policy on the pod. Joining them is the exercise.

Exercise 2: write the consequence list. One hour.

1. From the tool registry, write one row per tool: the verb it performs.
2. From the IAM or service-account policy, write what each verb can reach: which tables, buckets, APIs, records.
3. From the network policy, write which destinations the agent can open a connection to.
4. Combine into rows of verb, object and destination. Mark each row as gated (a human or second system must approve) or ungated (completes on the model’s say-so).

Done looks like a table with somewhere between ten and forty rows, most of them ungated. That table is the denominator every test is defined over, and you now have it.

Lesson 3: Delivery Decides Who Can Attack You

Direct injection arrives from the user. Indirect injection arrives from content the agent reads on the user’s behalf, and once the text is in context the two are identical. The distinction matters before that point, for one reason: it tells you who can write.

A source only the agent’s own operators can write to is a low-exposure source. A source any customer can write to, such as a ticket queue, is a high-exposure one. A source anyone on the internet can write to, such as a public web page or a public repository issue, is the widest. Tool descriptions count as a source, and a poisoned description can carry an instruction that fires on a later, legitimate call, so the supply chain of the tools themselves is a writer too.

Exercise 3: annotate the source list with writers. One hour.

1. Take the source list from Exercise 1. For each source, write who can put text there: operators only, authenticated customers, anyone, a third-party vendor.
2. Sort the list by widest writer first.
3. For the top three, note which rows of the consequence list an instruction arriving there could reach.

Done looks like the source list re-sorted, with the three sources that give the widest population a path to the most consequences at the top. Those three are where the first tests go.

Lesson 4: Filters Are a Rate and Unreachability Is a Property

A classifier in front of the model lowers the fraction of injected instructions that get through. Removing a tool makes the consequence impossible regardless of what gets through.

Those are different kinds of control, and every prevention claim is really a claim about which kind you used. A rate depends on the payload: filters score override phrasing and encodings well and score a plain sentence as the ordinary text it is. A property depends on nothing the attacker writes: a credential scoped to single-record reads cannot do a bulk read, and an egress policy with no route cannot exfiltrate to that route.

Keep the classifier. Attackers in the wild reuse templates, and a filter tuned to them removes real volume. Just file it under rate, and spend this lesson’s hour on a property.

Exercise 4: make one row unreachable. One hour, plus a change window.

1. From the consequence list, pick one ungated row the agent has never actually needed. Dormant permissions are the usual candidates.
2. Remove it: unregister the tool, narrow the credential, or drop the egress route. None of these touch the agent’s code.
3. Verify by test. Write one plain-language request for that consequence, place it in the widest-writer source from Exercise 3, and confirm the action fails with access denied.

Done looks like one row moved from reachable to unreachable, with a test result next to it. The move did not slow the pipeline and did not break production, because the row was never used. Most consequence lists have several of these.

Lesson 5: When the Text Is Clean, Behavior Is the Evidence

The payload most likely to reach your production data is a grammatical sentence asking for an authorized action, and it leaves nothing in the prompt for a filter to find.

That is the tier of technique that performs no evasion, and the record it leaves is entirely on the action plane: a tool call with arguments, a credential exercised against a table, a connection to a destination. Those are visible from the kernel whether or not the prompt looked suspicious.

They are only evidence relative to the agent’s own history. A database read is routine for a reporting agent and unprecedented for a ticket summariser, and a fleet-wide rule cannot say which is which. ARMO records what each workload actually does in execution with an eBPF sensor and builds a per-agent profile, Application Profile DNA (APD™), then evaluates each new action against it. The case it exists for is coercion: every step authorized, the sequence the attack. Turning that into a boundary follows the Audit and Enforce sequence, observing first, reviewing what a policy would have blocked against real traffic, then arming per agent, which is the sequence a platform team can accept because nothing blocks until the evidence says it can. One thing to budget for: a baseline takes real traffic to converge, and every agent ships before its own history exists.

Exercise 5: trace one action to its record. One hour.

1. Pick one ungated row from the consequence list that the agent uses legitimately.
2. Trigger it through normal use, and note the time.
3. Find every place your stack recorded it: application log, tool-call trace, cloud audit log, kernel-level telemetry, whatever you have.
4. Check whether the record names this agent, or only the pod, node or shared service account.

Done looks like one action with a list of the records it left, and an answer to the attribution question. If the answer is “the pod,” that ceiling decides what every finding above it can conclude, and it is the next thing to fix.

ARMO’s runtime security for AI workloads is the record Exercise 5 is looking for, scoped to the agent. Bring one agent’s consequence list to a working session and Exercises 4 and 5 run against its actual runtime profile.

The Week Ends With Three Lists and One Test

Sources, consequences, writers. One row made unreachable and verified. One authorized action traced to a record that names the agent.

That is the position every deeper piece of work on this problem assumes you are starting from: the consequence list becomes a test ledger, the writers list decides where tests are delivered, the recorded action becomes the first entry in a behavioral baseline. None of it required reading the technique catalog, changing the agent’s code, or blocking anything in production.

Next week the lists get longer, because you will attach a tool. Add the row before you attach it.

FAQ

Where should a beginner start with prompt injection for AI agents? With Exercise 1: list every source of text your agent reads and the path each one takes into the context. It takes an hour, needs only the agent’s configuration, and every other exercise consumes it. Definitions and mechanism can wait a day; the source list cannot, because it is where the attacker’s options are.

Do I need to learn jailbreak techniques to secure an agent? No. Jailbreak techniques defeat a model’s refusal training, and an agent attack has no refusal in the path: the attacker wants the agent to perform an action it is already permitted to perform, and a plain sentence does that. Learn the mechanism once, then spend the time on the permission set, which is the thing the attacker’s sentence can reach.

How long does it take to secure an agent against prompt injection? A week to know where you stand, which is what the five exercises produce. Moving consequences from reachable to unreachable is ongoing work, one row at a time, and the cheapest rows are dormant permissions the agent never used. Behavioral detection and enforcement take longer to arm, because a baseline needs real traffic before a policy can be trusted against it.

What tools do I need for the exercises? The agent’s configuration and tool registry, the IAM policy on its service account, the network policy on its pod, and whatever logging your stack already has. Nothing in the five exercises requires changing the agent’s code or installing anything in it. Exercise 5 will show you whether the logging you have can name the agent, which is the first tooling gap most teams find.

How do I explain prompt injection to a CISO in one sentence? An instruction from an untrusted source, followed by a model that cannot tell instructions from data, acted on by an application with its own authority. The third part is the one that makes it a security incident, and the consequence list from Exercise 2 is the document that shows the CISO how large that third part currently is.