Assume the injection succeeds.
How an agentic workflow is constrained after prompt injection works. A language model follows instructions in its context window, and no current technique reliably distinguishes the instructions you gave it from instructions an attacker placed in a document, an email, a calendar invite, or a web page the model was asked to read.
So the design review question that matters is not how you prevent prompt injection. It is what the attacker's instructions can actually do once they are executing with your agent's privileges. Six layers, six inspectable questions.
Prompt injection is not a bug that gets patched.
Prompt injection has held the top position on the OWASP Top 10 for LLM Applications since the list has existed, and it holds it again in the 2026 edition. There is a reason it never moves. Input filtering, adversarial training, and guard models all reduce the rate; none of them take it to zero, and OWASP’s own guidance says so. The 2026 edition is also the first to rank on evidence as well as judgment — 6,639 classified real-world incident records, weighted at 25 percent alongside the practitioner vote — so the list now reflects what actually goes wrong, not only what practitioners fear.
So when we review an agentic workflow, we ask: assume the injection has already succeeded — the attacker’s instructions are now executing with your agent’s privileges. What can they actually do?
This is no longer a contrarian stance; it is where the field has settled. The 2026 OWASP edition opens by telling its readers to stop trying to build a model that cannot be fooled and to build the system around it so that, when the model is fooled, nothing important breaks. Underneath, it is the assume-breach posture security teams have applied to phishing for two decades, applied to a new kind of credential: the context window. An organization that treats employee phishing as inevitable and engineers containment around it should treat agent injection exactly the same way. What follows is the containment stack we expect a defensible design to show, layer by layer — and, just as important, what each layer does not do.
Six layers, and the limits of each.
Every layer below is an old idea aimed at a new actor. Each ends with the thing it cannot do — because a control whose limits are unstated is a control that gets trusted for the wrong job.
01The agent’s identity is not your identity
The first thing an injected instruction inherits is whatever the agent can authenticate as. If the agent operates with a person’s full credentials — their email, their document store, their admin tokens — then a successful injection is that person, for as long as the session lasts. A contained design gives each agent its own identity: distinct credentials, scoped to the specific systems the workflow requires, ideally short-lived and issued per task rather than standing. This is nothing more exotic than least privilege (NIST SP 800-53, AC-6) and unique identification of non-person entities (the IA control family), applied to a class of actor that most identity programs haven’t onboarded yet. The test is simple to state: name every system the agent can touch, and for each one, name the narrowest permission that still lets the workflow complete. Anything broader is blast radius you chose to carry.
What this layer does not do: it cannot stop misuse within the granted scope. An agent legitimately allowed to send email can be injected into sending the wrong email. Scoping bounds the damage; it doesn’t eliminate it.
02Tools are allow-listed outside the model
An agent acts through tools — send, write, execute, purchase. The 2026 OWASP list promotes Excessive Agency into its top three, which matches what we see: agency creep, where a workflow accumulates capabilities because granting them was easier than scoping them. Two properties matter. First, the tool list is an explicit allow-list, deny by default: the agent can invoke exactly the tools the workflow was approved to use, and nothing else, no matter what the model asks for. Second — and this is the property that gets missed — the enforcement point lives outside the model. A rule written into the system prompt (“never call the payments API”) is a suggestion to the very component the attacker now controls. A rule enforced by deterministic code between the model’s request and the tool’s execution is a control. OWASP’s Securing Agentic Applications guidance makes the same distinction; so does every prior generation of security engineering, which never confused policy stated in a document with policy enforced in a reference monitor.
What this layer does not do: it cannot stop an allowed tool from being used for a harmful purpose — the classic confused-deputy problem. The allow-list defines the attack surface; the remaining layers constrain what crossing it can accomplish.
03Retrieval is bounded, and the boundary is server-side
Retrieval cuts twice in an injected workflow. Whatever the agent can read is whatever the attacker can now attempt to exfiltrate. And retrieved content is itself the injection vector of consequence — indirect injection through poisoned documents and RAG stores is documented at length in MITRE ATLAS’s generative-AI techniques and in OWASP’s vector-and-embedding-weaknesses category. A contained design bounds retrieval the way it bounds tools: the agent’s identity determines which data stores, which partitions, which sensitivity tiers it may query — enforced at the data layer, server-side, on every request. Filtering the results after an unbounded query, in application code or in the prompt, fails open: one bug, one bypassed code path, and everything is readable. Fail-closed means the query that isn’t explicitly authorized returns nothing, including when the authorization service is down. Where data of different sensitivities serves different populations, that separation is a structural boundary (the AC-4 information-flow family), not a metadata tag the model is asked to respect.
What this layer does not do: it cannot protect the data the workflow legitimately needs. What the agent can rightly read, an injection can attempt to move — which is why the next layer exists.
04Egress is denied by default, and the denial doesn’t live in the agent
Exfiltration is the payoff of most realistic injections: read something valuable, then transmit it somewhere the attacker controls — an outbound web request, an email, a URL parameter, a webhook. The containment is old-fashioned network security applied without sentiment: default-deny outbound, an explicit allow-list of destinations the workflow genuinely requires, and every denied attempt logged and alerted. The property to inspect is where the denial is enforced. If egress policy is a proxy setting the agent’s process is asked to honor, an injected agent can be instructed to ignore it. The control must sit outside anything the model influences — at the network boundary, in the host firewall, in infrastructure the agent’s runtime cannot reconfigure. This is boundary protection (SC-7) doing exactly its historical job for a new class of insider.
What this layer does not do: it cannot inspect intent on approved channels. If the agent may email customers, a poisoned email to a customer traverses the allow-list legitimately. Approved channels are constrained by the next layer.
05Irreversible actions wait for a human
Some actions can be undone; a category cannot: funds moved, contracts sent, records deleted, anything published externally. A contained workflow enumerates its irreversible actions explicitly and places each behind a human approval gate — not a notification, an approval, with the action held until it arrives. The design detail that separates a real gate from a decorative one is what the human sees and how often. An approver shown the actual diff — this recipient, this amount, this content — can catch what an approver shown “the agent requests approval” cannot. And a gate that fires forty times a day trains its human to click yes; approval fatigue is the known failure mode of every review gate ever built. Consequential actions are approved individually, never batch-approved, and if the volume makes that intolerable, that is evidence the workflow’s autonomy is scoped wrong — not evidence the gate should be loosened. NIST’s AI RMF and its Generative AI Profile place this human oversight squarely in the Govern and Manage functions: it is an organizational control with an owner, not a UI feature.
What this layer does not do: it cannot catch what a tired human approves, and it does not scale to high-frequency actions — which is precisely why the earlier layers must shrink what ever reaches it.
06The log can reconstruct the incident
When the injection is discovered — usually later, usually indirectly — the first question is what happened, and the log either answers it or it doesn’t. Reconstruction requires, at minimum: the agent’s identity and credential scope at the time; what was retrieved, with sources; every tool invocation with its full arguments; every policy decision, including denials — the denied attempts are where the attack becomes visible; every human approval, with what the approver was shown; and the model and configuration versions in play. The log itself sits outside the agent’s write access (AU-9 — an actor that can edit its own audit trail doesn’t have one) and is retained per the AU family’s event-logging and retention discipline.
What this layer does not do: nothing here is preventive. Logging is how you find out, bound the damage, and prove what did and did not happen — including to a regulator. It is also the layer that makes every other layer testable.
Nothing above is novel. That is the point.
Identity scoping, reference monitors, information-flow boundaries, default-deny egress, human authorization of irreversible actions, tamper-resistant audit — these are the oldest ideas in the field, aimed at a new actor that is best modeled as an enthusiastic employee with no judgment who believes everything they read. The frameworks now say the same: OWASP’s 2026 LLM Top 10 and its Agentic Security Initiative guidance, NIST’s Generative AI Profile, and MITRE ATLAS’s agentic techniques all converge on containment-by-architecture rather than trust-in-model. The 2026 edition’s own crosswalk puts a number on it: prompt injection and excessive agency each map to seven of the ten agentic-application risks, and no other entry reaches more than three — contain those two failure modes and you have addressed most of what can go wrong in an agentic system.
When we review an agentic workflow, we are not asking whether its model is clever or its vendor is reputable. We are asking six inspectable questions — one per layer — and the design either shows its answers or it doesn’t. Apogee does not build these systems and does not sell any of the components named above. That is deliberate: the review is only worth something if the reviewer has nothing to sell you at the end of it.
Standards referenced (all verified current, August 2026): OWASP Top 10 for LLM Applications, 2026 edition (genai.owasp.org); OWASP Agentic Security Initiative — Agentic AI: Threats and Mitigations, and Securing Agentic Applications Guide 1.0; NIST AI Risk Management Framework 1.0 (NIST AI 100-1) and Generative AI Profile (NIST AI 600-1); MITRE ATLAS (atlas.mitre.org); NIST SP 800-53 Rev. 5, Release 5.2.0 — control families AC, IA, SC, AU.
This is the lens we review agentic designs through.
The six questions above are the review standard behind our AI implementation advisory — use-case viability, data boundaries, requirements a development team can build against, and controls through the build.