Druhin Dhavala published an API-gateway guide to stored prompt injection on October 26, 2026, tracing how adversarial text can enter through an authorized write, sit in a database and later influence a more powerful AI agent.
The guide’s central concern is a gap in enterprise security architecture: permission to store or retrieve a record says little about whether an agent should obey instructions inside it. A gateway can validate a token, accept a correctly shaped request and enforce access policy while still passing along text that becomes dangerous downstream.
Dhavala presents an engineering perspective, not a newly discovered vulnerability or an independently verified attack. He describes thirteen years working around API gateways and explicitly says he has not built AI agents. His historical API incident is an analogy; the agent attack he develops from it is a thought experiment.
That distinction makes the piece useful as an implementation guide. Its strongest contribution is a way to examine the boundaries between systems that each appear to be doing their job correctly. For agent builders, the practical question is where stored content gains influence over tools, credentials and network access.
How an Authorized Write Becomes an Agent Instruction
Stored prompt injection is adversarial text written through a legitimate path and later read by an agent that treats it as instruction. The storage location might be an applicant record, a customer-service note or another field that an agent eventually retrieves.
Dhavala illustrates the problem with a request such as PATCH /v1/crm/accounts/{id}. A gateway checks the request’s JSON schema, validates its token and asks Open Policy Agent, or OPA, whether the caller may access the route. All those checks can pass.
None answers a different question: should a downstream agent follow a command embedded in the notes field?
A schema can constrain a field’s type and length. Access policy can determine whether a principal may update an account. Those controls are valuable, but ordinary free text can contain both useful business information and an attempt to redirect the agent processing it.
The guide’s hypothetical attack unfolds over a much longer period than a single request:
- An attacker submits a résumé containing a concealed instruction to retrieve bank routing information and send it to an external address.
- An ingestion agent processes the document and writes applicant notes through an authorized API.
- The record remains in storage for months.
- A more privileged finance agent reads historical records during an audit.
- If the hostile instruction survives ingestion, influences that agent and reaches an available outbound tool, it can become an attempted action.
Those conditions matter. The guide does not demonstrate that a particular model preserves the instruction during summarization, follows it later or successfully exfiltrates information. It explains an architecture in which that chain could occur.
Dhavala summarizes the authorization problem this way:
“The attack lives in the gap between two correct decisions.”
The guide’s hypothetical separates the legitimate write from the legitimate read. The security failure arises when content retrieved by the second operation acquires authority over what the agent does next.
My view is that this is the most useful distinction in the article. Teams can review every endpoint and still miss the connection between a low-trust writer and a high-privilege reader. An agent’s effective attack surface includes the records it consumes, including records created long before the agent existed.
The API Incident Behind the Analogy
Dhavala grounds his argument in a historical incident involving Apigee, an Istio service mesh and a Key-Value Map, or KVM.
In his account, a public-facing Apigee proxy accepted an external payload of about 1 MB. The edge applied OAuth validation, a web application firewall and regular-expression filtering. Several internal services then transformed or split the payload.
Three calls into the chain, an intermediate service extracted a string and wrote it to an Apigee KVM without validating it at that boundary. The KVM-owning team assumed upstream systems had sanitized the value. The edge team assumed downstream applications would not execute raw data.
The stored string was a curl command. According to Dhavala, an application consumed it and began repeatedly calling an external endpoint. An outbound firewall rule blocked the traffic from leaving, although a CPU spike remained.
The same account describes a separate authorization problem: a value from the original payload could become an internal request header identifying another user’s account. Internal services trusted their peers without checking the end user’s authority over the requested object. Dhavala identifies that as broken object-level authorization, or BOLA.
These are the author’s reported experiences, not incidents independently investigated for this article. They also involve conventional API and application behavior, not an observed AI-agent compromise.
Their relevance is structural. In both the historical account and the proposed agent scenario, data enters through an allowed interface, moves through trusted infrastructure and reaches a component capable of acting on it. Trust in the transport gradually becomes trust in the content.
The egress rule is especially instructive. It reportedly prevented outbound traffic without fixing the unsafe interpretation that caused it. For agent systems, I would treat that as a strong argument for independent containment controls: preventing a bad decision and limiting its consequences are separate jobs.
Revalidate at Boundaries Where Meaning or Authority Changes
“Validate every hop” needs a precise implementation. Repeating the same schema check at every service will not resolve a prompt-injection problem if a perfectly valid string is later treated as a command.
A more useful interpretation is to revalidate the assumptions that change at each boundary.
| Boundary | Assumption to challenge | Practical control |
|---|---|---|
| External input enters an API | A valid request contains trustworthy text | Enforce input contracts while retaining the content’s external origin |
| A service transforms or stores data | An internal writer makes the content trusted | Preserve source identity and transformation history separately from the text |
| An agent retrieves a record | Read permission makes embedded instructions authoritative | Separate retrieved material from the agent’s governing instructions |
| An agent proposes a tool call | A plausible request is permitted for this task | Validate the tool, target, arguments and authorization outside the model |
| A tool sends data or changes state | The agent’s identity is sufficient approval | Apply narrow permissions, destination restrictions and approval where needed |
This table is an implementation analysis of the guide’s threat model, not a control set tested by its author.
Identity deserves particular care. A downstream service may need to authenticate the calling workload and determine the user or task on whose behalf it is acting. A trusted service identity alone cannot answer whether a particular account, document or financial object is within scope.
For an agent, that creates two distinct checks. May the agent retrieve the record? And may it perform the proposed action using information from that record?
The second check should happen where the action is enforced. If an agent can call a payment, messaging or webhook tool, the receiving service should enforce the relevant policy even when the request arrives from an authenticated agent runtime.
This avoids making the model the final authority over its own permissions. The model can propose an action; application code and policy enforcement determine whether the action may proceed.
Preserve Provenance Through Storage and RAG
Provenance answers where content came from and what happened to it. It becomes particularly important when retrieval-augmented generation, or RAG, places stored records into an agent’s context.
A database row can be internal while its text originated in an external email. A summary can be generated by an internal service while preserving an attacker’s request. A search result can be relevant to the task while carrying instructions the agent should ignore.
The storage system’s location does not resolve those differences.
A practical provenance design could record:
- Original source: the submitting user, external document or connected system.
- Ingestion path: the API and service that accepted the content.
- Transformation history: extraction, summarization or other processing applied before storage.
- Access scope: the tenant, account or workflow to which the material belongs.
- Content role: whether it is externally supplied material, an internal annotation or an approved instruction.
These are proposed design fields, not metadata requirements quoted from Dhavala’s guide. Their purpose is to make the trust decision inspectable.
The metadata itself needs an integrity boundary. An attacker-controlled document claiming to be approved policy is still an attacker-controlled document. Trusted infrastructure must attach and protect authoritative labels; the body text cannot award itself a higher trust level.
Summarization also deserves scrutiny. The hypothetical attack depends on malicious instructions surviving ingestion in some form. Treating every model-generated summary as clean would simply move the trust decision to an earlier model call.
For RAG systems, I would prioritize preserving the distinction between retrieved evidence and governing instructions over trying to make every retrieved paragraph appear safe. That distinction can guide prompt construction, tool policy and audit records. It cannot, by itself, guarantee that a model will never follow hostile text.
The broader verification work is already organized around related system boundaries. OWASP’s Large Language Model Security Verification Standard v2.0, published in 2026, explicitly clarifies the scope of its storage section for RAG-style retrieval and its agents section for tools and protocol-based connectors. It provides a security-verification framework; it is not evidence that the specific attack in Dhavala’s guide has been demonstrated.
Frequently Asked Questions
4 questions
1Is This a Newly Discovered Vulnerability?
No. The guide applies the established concept of stored or indirect prompt injection to enterprise API chains. Its AI-agent attack is explicitly hypothetical.
