When web content becomes an agent instruction

tl;dr

Instructions aimed at AI systems are already present on public webpages and, according to one reported investigation, in HTTP response headers. The reviewed evidence establishes in-the-wild payload placement. It does not establish widespread compromise of deployed agents.

The dangerous moment occurs inside the application: attacker-controlled resource data enters model context, changes a plan, and passes an authorization layer that lets the agent act. A page, email, document, header, redirect, or tool result can carry the instruction. Each carrier matters only when the implementation exposes it to the model.

Security teams can reduce the risk by inventorying every representation their tools ingest, preserving provenance, treating model-generated actions as untrusted proposals, binding authorization to the user’s current intent, limiting credentials and egress, and correlating resource ingestion with later actions and independently verified effects.

The hidden instruction may sit outside the page

A user asks an agent to compare products. The agent fetches a supplier page. Alongside the facts the user wanted, the resource contains text intended to influence an AI system. That text may be visible in the page, concealed in markup, stored in metadata, assembled by script, or present in a response field a person would never see.

This is indirect prompt injection. NIST AI 100-2e2025 distinguishes it by attacker control of a resource that the system later processes. The immediate user is not supplying the hostile instruction. The resource is.

In this article, “real world” means that researchers reported prompt-like text on live or publicly captured resources. It does not mean an agent was proved to have read that text, obeyed it, or caused harm. Those are separate evidentiary steps.

This is product-agnostic threat research. We did not inspect an agent binary, model endpoint, operating-system client, browser tool, or fetcher. The procurement workflow below is synthetic. Product behavior changes with the model, parser, orchestration, policy, permissions, and version, so every ingestion and control claim must be verified in the system being assessed.

Input pattern	Who controls the immediate path?	What the label tells us
Direct prompt injection	A user sends the instruction through the model or agent interface	The model-facing input channel carries an instruction that attempts to override constraints
Indirect prompt injection	Another party controls a resource the system retrieves	The instruction reaches the system through resource control
Benign AI-directed text	A publisher, researcher, or user writes about or for an AI system	Classification still requires context because prompt-like wording alone does not establish malicious intent

A trusted user objective and untrusted supplier content both enter a model context. The expected path produces a comparison draft. A conditional path lets resource text steer the plan.

Trusted objectiveCompare products and prepare a draft

Untrusted resourceProduct facts plus resource-controlled text

Both become model-visible

Context and plannerFacts and instructions compete for influence

ExpectedComparison draft

ConditionalPlan drifts beyond the user's objective

A trusted tool can retrieve a resource without making the resource's instructions trusted.

The distinction matters because ordinary web text can resemble a prompt for benign reasons. A publisher may discourage automated access. A researcher may host a test. A page may discuss prompt injection. Site ownership, motive, model ingestion, and effect cannot be inferred from the presence of a string alone.

Follow one synthetic agent from retrieval to effect

Consider a fictional procurement analyst who asks an agent to compare office chairs from several approved supplier pages and prepare a purchase-request draft. The agent can browse public sites, read an internal budget, create a draft, and submit a request only after specific human confirmation.

The user has authorized research and drafting. They have not authorized submission, disclosure of the budget, a new supplier, or a new recipient.

Seven steps show a user objective, resource retrieval, context assembly, model planning, policy review, tool access, and a possible external effect. The effect occurs only if several implementation and authorization failures align.

1. 1User objectiveCompare and draft
2. 2FetchSupplier controls returned bytes
3. 3AssembleSelected fields enter context
4. 4PlanResource text may influence action
5. 5AuthorizePolicy checks intent and parameters
6. 6Invoke toolDraft, message, or submit
7. 7External effectChanged data, recipient, or state

Boundaries hold: the workflow ends at an accurate draft.

Boundaries fail: an out-of-scope proposal reaches a consequential tool.

Here is where the chain can break down:

1. Retrieval. A fetch tool requests a supplier resource. The origin controls visible copy, markup, metadata, response fields, redirects, linked resources, and potentially time-dependent content.
2. Context assembly. The application flattens some of those representations into text beside the user’s request. This is the decisive question for a header-based injection: which exact fields and values become model-visible?
3. Trust collapse. The model receives resource facts and resource-authored instructions through the same reasoning path. A “web result” label or delimiter may help, but it cannot enforce authority.
4. Planning drift. The model proposes changing the supplier, contacting a new destination, attaching internal data, or submitting the request.
5. Authorization failure. The broker checks that the agent possesses a tool and that its parameters are syntactically valid. It fails to check whether the action, target, destination, data, amount, and identity follow from the current user objective.
6. External effect. A service records a message, purchase, file change, approval, deletion, or network transfer. A transcript showing a proposed call or a tool reporting success is not independent proof of this stage.

Every step is conditional. A hostile instruction that never reaches the model cannot influence it. A changed plan cannot create an external effect if policy denies the tool call. A least-privileged, draft-only agent has a lower impact ceiling than an agent with payment, messaging, file, and network authority.

“The webpage” is several different inputs

People see a rendered page. Agents may receive a different representation. Depending on the browser, fetcher, parser, OCR layer, and orchestration code, “the page” can include raw HTML, an accessibility tree, extracted text, image text, structured metadata, errors, redirect history, or response fields.

An HTTP response and related resources fan out into response fields, source markup, rendered content, metadata, redirects, and extracted text. Implementation-specific switches determine which representations enter context.

Origin-controlled resourcecatalog.example.invalid

• ProtocolStatus and response fieldsConditional carrier
• SourceHTML, comments, attributesMay differ from the view
• RenderedDOM and accessibility treeIncludes dynamic content
• StructuredMetadata and document propertiesOften visually quiet
• TraversalRedirects and linked resourcesMay cross origins
• ExtractionText, OCR, errors, tool summariesTransformation can lose provenance

Context builderExplicit, version-specific selection

Body-only scanning misses fields it never inspects. Body-only context also prevents a response header from influencing the model.

RFC 9110 separates HTTP fields from optional message content and defines representation metadata. It does not require an AI application to send arbitrary fields to a model. A header becomes an injection carrier only if a fetcher, parser, trace, diagnostic wrapper, browser layer, or other component serializes attacker-controlled field data into model input.

This conditional boundary is easy to miss. A security control may scan extracted body text while an error handler supplies selected headers to the model. The reverse is also possible: a network collector records suspicious response fields, but the agent sees rendered body text only. Investigators need evidence of actual context assembly before attributing influence.

Four examples show how a carrier could become an action

The following examples are synthetic reconstructions for the fictional procurement workflow. They are not payloads from the cited research, product tests, or incidents. The marker text is inert, the domains and identifiers cannot reach a real recipient, and each chain ends at the independent decision that should prevent an external change.

Across all four examples, the resource supplies data and the model supplies a proposal. Authority comes from a separate policy decision. The safest observable outcome is a denied proposal with no service-side change. If a consequential action is allowed, investigators still need the destination system’s record to establish what happened.

The same principle extends beyond websites:

Resource under another party’s control	Possible carrier	Capability that raises the impact ceiling
Advertisement or marketplace listing	Body, hidden markup, attributes, dynamic content	Moderation or approval API
Email or support ticket	Message, quoted thread, attachment, calendar invite	Customer records and reply tools
Repository issue	Issue, comment, README, dependency documentation, tool output	Filesystem, shell, Git, CI, network
Candidate application	Resume, portfolio, document properties	Ranking or workflow status
Security investigation target	Page, fields, certificate or banner text, scanner output	Browser, ticketing, blocklist, notifications

TLS and a trusted connector protect transport or authenticate access. They do not grant instruction authority to the resource author.

Separate public placement from successful compromise

Three user-supplied investigations describe public-web prompt injection from different angles. Together they establish a useful warning: people are placing AI-directed content in resources that agents may retrieve. Each source also leaves important stages unproved.

Four ascending evidence levels run from observed placement through attempted exploitation and controlled susceptibility to confirmed downstream effect. The three public-web reports support mainly the first two levels. The reviewed cases do not fill the confirmed-effect level.

1. 1Observed placementAI-directed text exists in a live or publicly captured resource.Google · Unit 42 · SecurityBreak
2. 2Attempted exploitationThe content expresses a plausible objective and appears positioned for an AI consumer.Some reported examples
3. 3Demonstrated susceptibilityA controlled test shows an agent following injected content under defined conditions.NIST evaluations · research systems
4. 4Confirmed downstream effectIndependent evidence proves a deployed agent caused the claimed external change.Unfilled for the reviewed public-web cases

Before interpreting individual findings, map each evidence source to the question it can answer:

Evidence source	Best question it answers	Boundary it cannot cross
Google Threat Intelligence Group public-web study	What kinds of prompt-like material appeared in sampled Common Crawl snapshots?	It does not show that a deployed agent retrieved or followed a particular page
Unit 42 live-page observations	Which placement and presentation techniques, apparent objectives, and severity scenarios appeared in the vendor’s material?	It does not establish a reproducible prevalence rate or confirmed effect in its highlighted ad-review case
SecurityBreak response-field report	Can AI-directed text be placed outside the page body in live HTTP responses?	It does not show that a named agent ingested or obeyed the reported fields
NIST controlled evaluations	Can indirect instructions influence agents under defined test conditions?	Benchmark results do not estimate public-web incident frequency
RFC 9110 and secure-agent guidance	Where are protocol and authorization boundaries, and which controls should systems apply?	Standards and design guidance do not establish product-specific behavior or control effectiveness

Google found a varied, mostly low-sophistication population

The Google Threat Intelligence Group investigation used Common Crawl snapshots, pattern matching, Gemini classification, and human validation. Human review mattered because simple matching found many benign pages discussing prompt injection.

Google grouped the material into pranks, helpful guidance, search manipulation, attempts to deter agents, and a smaller malicious category that included apparent data-theft or destructive objectives. It characterized sophistication as limited and many examples as experiments or pranks.

The study provides no absolute candidate or validated counts, base rate, released labelled corpus, or full classifier error measurements. Common Crawl also excludes much login-walled, anti-crawl, and social content. Its reported relative trend cannot support a claim about global prevalence, and a captured page does not show that an agent encountered it.

Unit 42 mapped varied carriers and apparent objectives

Unit 42 reported prompt-like content on live sites and classified 22 payload-engineering techniques. These covered visual concealment, placement in markup and attributes, dynamic assembly, encoding, multilingual instructions, and authority-style presentation. The number 22 describes taxonomy categories. It is not an incident count.

One highlighted page contained repeated hidden instructions apparently aimed at influencing an AI advertisement reviewer. Unit 42 explicitly said it was not aware of a successful attack against a deployed ad-checking agent. The evidence supports observed placement and an apparent bypass attempt. It does not show ingestion, approval, a victim system, or downstream effect.

The report does not publish enough about its telemetry, collection window, denominator, full corpus, or per-technique counts for independent prevalence estimates.

SecurityBreak extended the carrier question to headers

SecurityBreak reported AI-directed strings in live HTTP response fields found through Shodan, Censys, and its own beta service. The examples broaden the surface defenders should inventory because headers sit outside the visible page body.

The report does not demonstrate a named agent ingesting or obeying a header. It also omits a collection interval, full query corpus, denominator, deduplication method, preserved dataset, and independent validation. Host ownership and intent remain uncertain. Some text may come from researchers, pranks, challenges, honeypots, anti-automation messages, or other operators.

Across all three investigations, the strongest common conclusion is public placement and experimentation. The evidence reviewed here does not show widespread successful compromise of agents.

Controlled evaluations answer a different question. NIST’s AgentDojo analysis and its later large-scale red-teaming competition show that indirect instructions can influence agents under defined test conditions. Those results demonstrate susceptibility in particular models, scaffolds, tasks, tools, and retry policies. They do not measure production-incident frequency.

Architecture sets the impact ceiling

A text-only summarizer can still omit facts, bias a recommendation, or produce attacker-chosen output. An empowered agent can expose private data or change an external system when its accessible data, tools, credentials, egress, and authorization permit that outcome. OWASP LLM01:2025 similarly ties impact to business context and agency.

Risk rises when several conditions align:

• the workflow retrieves a resource another party can influence;
• the relevant representation actually enters model context;
• resource content can affect planning or tool selection;
• private data or secrets share the same decision path;
• tools can communicate, pay, publish, execute, write, or delete;
• credentials are broad, long-lived, shared, or detached from the user’s purpose;
• retrieved content can select a new external destination;
• authorization checks possession of a tool without checking current intent;
• confirmation hides the exact target, data, destination, amount, or effect;
• telemetry cannot connect the resource to the proposal and verified outcome.

Possible harm includes manipulated decisions, disclosure through an allowed channel, resource exhaustion, unauthorized workflow changes, and destructive action. A second failure can also turn model output into executable markup, a command, a query, or an instruction for another agent. Prompt injection and cross-site scripting are distinct failures: XSS requires unsafe output to reach an executable rendering context.

Put independent gates between text and action

Current authoritative sources do not offer a complete prompt-injection prevention technique. Google DeepMind’s defense research argues for layered defenses and adaptive evaluation. CaMeL research explores separating control flow and data flow with capabilities. Google’s secure-agent framework emphasizes limited powers, current user intent, scoped credentials, revocation, and observable actions.

The practical design goal is to give every later boundary a chance to stop an earlier failure.

A sequence from retrieval to external effect has separate controls for representation minimization, provenance, model hardening, policy, scoped credentials, exact confirmation, egress, output safety, and telemetry.

1. RetrieveMinimize representationsAllowlist required fields and origins
2. AssemblePreserve provenanceKeep origin, field, transform, and purpose
3. ReasonHarden and evaluateUse adaptive, versioned tests
4. ProposeEnforce policy outside the planCheck identity, intent, data, target, destination
5. ActLimit authorityScoped credentials, sandbox, egress, exact approval
6. RenderValidate the final contextSchema checks, encoding, sanitization, safe sinks

Telemetry spans every gate so investigators can connect the retrieved input, policy decision, requested action, tool result, and authoritative effect.

Inventory and minimize what tools expose

For every retriever, record whether it can supply rendered text, raw HTML, accessibility data, OCR, metadata, response fields, redirects, errors, or linked resources. Pin this inventory to the tool and parser version. Pass only the representations required for the task. Use an explicit safe-field allowlist for response metadata and re-evaluate policy when a redirect crosses an origin.

Minimization reduces surface. It does not make retained content trustworthy.

Carry provenance through every transformation

Preserve the resource identifier, origin, retrieval time, redirect chain, representation type, and field or span through extraction and summarization. Represent external material as typed data with an allowed purpose. A resource-authored label such as “system” or “administrator” must remain resource data.

Delimiters, labels, classifiers, and hardened models can reduce susceptibility. They remain defense layers because the same model can still misinterpret or ignore them under adaptive attack.

Treat model actions as proposals

Place authorization on a decision path that does not inherit the model’s compromised reasoning. Evaluate each proposed tool call against:

• the authenticated user and delegated identity;
• the current, explicit objective;
• the action class and exact parameters;
• the resource and data sensitivity;
• the target and external destination;
• the amount, side effects, and reversibility.

Use short-lived, narrowly scoped credentials, read-only defaults, isolation, and restricted network and filesystem access. For consequential actions, show the person the exact action, identity, target, destination, sensitive data classes, amount, and effect. A generic “continue?” prompt carries too little information to restore the boundary.

Keep generated output untrusted at the next interpreter

Validate model output against a schema where possible. Apply context-specific encoding, sanitization, and safe sinks at the final renderer or interpreter. These controls contain second-order execution. They do not repair the earlier instruction-confusion failure.

Detect a chain, not a suspicious phrase

String matching is a useful lead, but the Google investigation shows why phrase-only detection produces false positives. A stronger signal connects an untrusted resource to scope expansion, a new destination, private-data access, a proposed action, and an external effect.

A seven-event timeline connects resource retrieval, carrier evidence, model decision, tool proposal, authorization, tool result, and independently confirmed effect using session, turn, resource, proposal, and service identifiers.

1. Resource fetchedsession_idresource_id
2. Field entered contextspan_refcontent_hash
3. Plan changedturn_idmodel_version
4. Tool proposedproposal_iddestination
5. Policy or person decidedpolicy_versiondecision_id
6. Tool reported resultcall_idstatus
7. Effect verifiedservice_event_idsystem of record

“Tool reported success” and “effect confirmed” are separate events.

Useful sequence detections include:

• an external resource enters context, followed by a proposal outside the requested tenant, repository, data class, recipient set, or action type;
• retrieval is followed by a message, upload, redirect, or transaction to a destination absent from the task and approved inventory;
• a sensitive read is followed by a communication or network proposal in the same session;
• a denied action is followed by another tool, encoding, redirect, or intermediary pursuing the same effect;
• model output containing markup, code, query fragments, or URLs reaches an unsafe interpreter;
• a response field contains AI-directed text unrelated to the body, followed by planning drift. This is a triage lead, not proof of compromise.

Collect the smallest sufficient, access-controlled record. Useful fields include the authenticated objective, explicit approvals, model and orchestration versions, parser and policy versions, resource provenance, selected representations, detector decisions, proposed parameters, human-confirmation display, tool results, and independent service outcomes.

Complete headers can contain authorization values, cookies, tokens, session identifiers, personal data, and keys. Do not copy them into general logs by default. Prefer safe-field allowlists, redaction, bounded retention, cryptographic hashes where suitable, and a separate protected evidence store when full content is necessary.

Respond by preserving the boundary crossing

If an injected run may have reached a consequential tool:

1. Pause the workflow or revoke its delegated authority when continued action could increase harm.
2. Preserve the resource representation supplied to the model, selected response-field evidence, redirects, transforms, versions, and timestamps.
3. Preserve the prompt, proposal, policy, approval, and tool records. Keep authoritative host and service logs as separate evidence.
4. Find other sessions that ingested the same resource, field value, content hash, origin, or redirect chain.
5. Verify messages, transactions, file changes, database writes, identity activity, and network destinations in their systems of record.
6. Revoke or rotate affected credentials when exposure or policy requires it, while retaining necessary forensic context.
7. Quarantine the resource at the relevant boundary and add a versioned regression test covering the full chain and alternate carriers.
8. Correct the authorization or architecture failure. A new string signature alone leaves the control gap open.

During triage, keep four states distinct: a tool was proposed, approved, invoked, or independently confirmed to have changed something. The agent’s own summary cannot collapse those states into proof.

Public attempts are an architectural warning

The public-web observations are meaningful because they show that resource owners and other actors are already writing for AI consumers. They are early evidence of experimentation across visible pages, hidden representations, and reported response fields. They do not establish broad successful compromise.

The durable security question is architectural: can external content inform a task without granting itself authority? Inventory the bytes that reach the model, keep their provenance, constrain the model’s powers, enforce the user’s current intent outside the model’s plan, and verify effects in independent systems. Those boundaries let teams use capable agents while keeping a hostile webpage from deciding what the agent may do.