The Inbox Is Not the Control Plane

The vending machine was an operating lesson

OpenAI's July 15 GPT-Red report is useful because the failure reached business state. In a live AI-powered vending system, the red-team model achieved all three assigned objectives: price an expensive in-stock item at $0.50, order an item costing more than $100 and offer it for $0.50, and cancel another customer's order. In a separate evaluation against GPT-5.1, it succeeded in 84% of novel indirect-prompt-injection scenarios, compared with 13% for human red-teamers.

This is red-team evidence, not a prevalence estimate. It does not show that 84% of deployed agents are compromised, and OpenAI said new safeguards for the vending system were being tested. It does show the mechanism cleanly: content the agent reads can steer tools that alter prices, purchases, and customer records.

NIST's March 23 report supplies a wider caution. More than 400 participants made over 250,000 attempts against 13 frontier models, and every target model had at least one successful hijacking attack. Certain attacks also transferred across models and scenarios. That does not make every attempt effective. It makes model choice one control, not the control plane.

The paperwork can carry orders

Indirect prompt injection is hostile instruction embedded in material an agent is expected to inspect. The operator asks for a legitimate job: read today's email, summarize a webpage, extract fields from a PDF, review a repository, interpret OCR, or process a tool result. The untrusted material then contains text designed to redirect the agent.

In business terms, it is a forged procedure slipped into the paperwork. The sender may claim a new payment destination is approved, that a diagnostic file must be uploaded, or that a customer order should be canceled. The human who started the task can be trusted while the artifact remains adversarial.

The inbox may report facts. It should not redefine the job, grant itself permissions, or approve the resulting action. A PDF with a logo is still input.

Filters do not get the final vote

On March 11, 2026, OpenAI argued that sophisticated prompt injection increasingly resembles social engineering. The attack may be plausible, contextual, and written like ordinary work, which makes filtering it similar to detecting deception without complete context. OpenAI's conclusion was that input filtering alone is insufficient; systems must constrain the impact even when manipulation succeeds.

Anthropic's current guidance, accessed July 16, recommends provenance labels, keeping untrusted content in tool-result blocks, stating that it cannot override instructions, JSON-encoding it where possible, limiting privileges, screening tool outputs, and testing with hostile documents and emails. Those are useful layers. None should be promoted into an authorization service.

The model can become more skeptical and the screen can catch more attacks. The remaining question is what happens on the miss.

Put a contract between source and sink

OpenAI describes the problem with source-sink analysis: an attacker needs a source it can influence and a sink that becomes dangerous in the wrong context. For an operator, the key diagram is therefore not the prompt. It is every path from untrusted content to an external side effect.

Label inputs when they enter the system. An authenticated owner instruction can define the job. Email bodies, fetched pages, uploaded files, OCR text, repository content, and third-party tool results remain untrusted evidence with preserved provenance. They may fill proposed fields. They may not change policy.

Then define an action contract for each sink. A price change should require a product identifier and pass a hard pricing rule. A purchase should pass a vendor allowlist and spending ceiling. A cancellation should match the authenticated customer's order. An external transmission should declare the destination and payload. Each schema should specify required inputs, scope, risk, execution limits, and logging.

The model proposes a structured action; deterministic orchestrator code validates it. Microsoft's guidance, last updated March 19, recommends explicit action schemas, no actions by default, least action and least privilege, and human review for high-risk or irreversible actions enforced through orchestrator logic rather than model reasoning. If approval is required, bind it to the exact target and parameters. "Proceed" should not become a bearer instrument.

Run the hostile-paperwork test

Before connecting a production sink, assemble a test pack from the workflow's real artifacts: benign emails, pages, PDFs, OCR extracts, repository files, and tool outputs, plus adversarial variants. Include both crude overrides and socially plausible claims of urgency or authority. Ask the test injections to expose data, alter a price, place an out-of-policy order, or cancel a different customer's work.

Use a scoreboard that measures benign-job completion, unauthorized sink executions, contract rejections by reason, human gates invoked, false positives, and review time. The release bar for the hostile corpus should be zero unauthorized high-risk actions. A system that blocks everything is not useful, so benign completion and operator burden belong beside the security result.

Set a hard stop condition: any unapproved sensitive transmission, out-of-policy price or purchase, cross-customer action, or irreversible write freezes the release. Preserve the trace, fix the source-sink boundary, and rerun the entire pack. An apologetic sentence after the tool call is not a pass.

The human gate should show the original work order, source provenance, proposed action, target account, amount or scope, expected effect, and available rollback. Approval should cover those exact parameters once; a changed payload requires a new review. Repeat the test after changes to the model, prompt, connector, tool schema, OCR, or retrieval layer. NIST's transfer finding is a good reason not to treat a model swap as a clean slate.

What the operator should buy

Inventory every untrusted-source-to-dangerous-sink path. Start new workflows in read or draft mode, then enable narrow action contracts one at a time. Buyers should ask vendors to run a poisoned-email or poisoned-PDF demonstration and show where the orchestrator rejects the action. "Human in the loop" is not an answer until the vendor can point to the code path that forces the loop.

The useful promise is not that the agent will never believe a lie. It is that believing one cannot silently become a payment, cancellation, price change, purchase, or data transfer.