Stored prompt injection hides in the gap between two correct API authorization decisions

What the post argues

A post on dev.to by a practitioner who says they have spent thirteen years building and operating API gateways lays out a security problem that emerges when AI agents read from and write to production databases through ordinary, fully authorized API calls. The author is explicit that they are not an AI specialist; the argument is built from a real API infrastructure incident they believe previews how stored prompt injection will behave as agents get attached to the same plumbing.

In that incident, described in the post, a public-facing Apigee proxy accepted a payload of roughly 1MB from the internet. The edge ran the expected checks, including OAuth validation, a web application firewall and regex filtering, then passed the payload inward through several services wrapped in Istio sidecars. Three calls deep, an intermediate service extracted a single string and wrote it to an Apigee Key-Value Map without validating it. The team owning the KVM assumed upstream had sanitized the data; the edge team assumed downstream would never execute raw data. The string was a curl command, and an application consuming that stored value began firing requests in a DDoS-shaped pattern aimed outside the company. A firewall rule that blocked anything not explicitly permitted stopped the traffic; the lasting damage was a CPU spike.

According to the author, the same chain also allowed a value such as another user's account number to be mapped into internal request headers, a broken object-level authorization flaw the sidecars never caught because they trusted the caller's position inside the mesh. The diagnosis was blind trust between hops, and the fix was unglamorous: strict input contracts and validation of the end user's token at every hop, not just the front door.

The agent version of the same chain

The post then maps that skeleton onto AI agents. A typical request such as a PATCH to a CRM accounts endpoint can pass three gateway checks, including schema validation, token liveness and a policy decision from Open Policy Agent, while carrying 5,000 words of inbound email in a notes field. The gateway validates the length; it does not read the words, and was never designed to. If a downstream system later loads that field into an agent's context, the words become instructions.

The author walks through a scenario they clearly label a thought experiment rather than a case study. Hidden text in a submitted resume tells any AI that reads it to fetch bank routing numbers and send them to an external URL. An ingestion agent summarizes the resume and writes it to the applicant record, and the policy engine approves the write. Nothing happens for months, because a text column passes every integrity check a database knows how to run. On day 180, a higher-privilege finance agent reads historical records during a quarterly audit, and that read is approved too. The raw string enters its context, and if that agent has a tool capable of outbound calls, such as a webhook sender, the instruction can act. Every call in the chain was authorized. There is no failed login to alert on and no schema violation in the logs.

Why an AI firewall is the wrong answer

The obvious response is to add a component at the gateway that reads text and judges whether it is malicious, an approach the industry is likely to market as an AI firewall, typically built on a second smaller model. The author rejects this: a guard model reading the same adversarial text amounts to another privileged worker rather than an actual governor. The author concedes this is an inference rather than a measured result, but sees no reason to assume text crafted to manipulate one model cannot manipulate another.

Provenance over content inspection

What the post proposes instead is to stop trying to judge content and be strict about what data is allowed to cause. Two mechanisms carry the idea. First, when an agent writes through the gateway, attach a signed provenance record containing the agent identifier, the data source, a classification such as unstructured external text, and a signature, stored in a companion column next to the value. This does not declare the text malicious; it records that it is untrusted and ensures that label survives the trip into the database instead of being stripped along the way. Second, make the read path act on that lineage. A draft OPA policy shown in the post defaults raw reads to denied and permits them for human-facing consumers, while autonomous agents receive the text wrapped as quoted, clearly marked untrusted data, never concatenated into instructions.

Why it matters

As organizations give agents tools and privileges, more unstructured external text will land in databases through legitimate API calls. Gateway controls verify structure and identity, not semantics, so both the write and the read pass every existing check, and the attack leaves no failed-authentication signal behind. The post argues the durable fix follows the pattern that worked against SQL injection and broken object-level authorization: propagate trust labels end to end and gate consequences, rather than trying to outsmart adversarial prose, because natural language has no equivalent of parameterized queries.