An agent that reads merchant websites crosses a trust boundary whenever page content influences its next action. A product description, hidden HTML comment or linked document can contain text that resembles an instruction. That material may be relevant evidence, but it is not authorized to redefine the user’s task or grant access to another system.
This threat model is a design proposal for a website-reading agent. It is not a claim that an AI browsing agent is deployed on this site or that any merchant has been attacked.
Identify assets and intended capabilities
List what the agent can access: public pages, private task context, credentials held by tools, generated reports and any connected application. Then list the actions it needs. A public-page audit may need to fetch a page and produce a report; it usually does not need email sending, account administration or arbitrary command execution.
The most useful boundary is often architectural. If a capability is unnecessary, omit it. A prompt asking the model not to use a powerful tool is weaker than not exposing that tool to the workflow.
Map the main failure paths
| Input or boundary | Potential failure | Design response |
|---|---|---|
| Merchant page text | Instructions embedded in evidence | Treat content as untrusted data |
| Links in the page | Navigation to unintended destinations | Validate scope and destination before fetching |
| Private task context | Accidental disclosure in requests or reports | Minimize context and restrict outbound data |
| Generated explanation | Unsupported claims or unsafe markup | Validate and render safely |
| Tool result | False or ambiguous completion | Verify the intended outcome independently |
| Repeated failures | Unbounded calls and resource use | Apply task, time and retry limits |
OWASP describes indirect prompt injection as a risk arising when external content influences model behavior. Its prompt-injection guidance supports preserving a distinction between instructions and inspected material.
Enforce network and action boundaries outside the model
A fetching service should validate allowed protocols and destinations, including redirects, and protect internal or local network resources. The model should not be responsible for deciding whether a URL is technically safe merely by reading its text. Credentials should remain in the tool layer and be scoped to the required action.
Similarly, publication or account mutation should require the application’s authorization rules. A page saying “send the report here” does not establish a user-approved recipient. A generated request must pass the same permission checks as any other request.
Separate observation from conclusions
Store the relevant evidence and collection limitations with each finding. The agent should distinguish “not observed in this capture” from “does not exist.” A blocked or incomplete fetch should produce an explicit limit, not an invented assessment of the merchant’s business.
The store-audit ground-truth guide provides an evaluation structure for these boundaries. It includes clean, ambiguous and adversarial cases so an agent that always produces confident findings is not rewarded.
Test the response to malicious-looking content
Use controlled test pages containing instruction-like text, misleading links and conflicting claims. Verify that the workflow continues to follow the original task, does not disclose private context and does not acquire new capabilities. Tests should inspect tool behavior as well as the final written answer.
Include ordinary failures too: slow pages, unexpected content types, oversized responses and unavailable destinations. Security controls should fail clearly without turning every inaccessible page into a suspicious incident report.
Plan containment and review
Keep a trace of allowed tool calls, decisions and outcomes without storing unnecessary secrets or personal data. Provide a way to stop a run and inspect what it actually did. When a failure is found, add a replayable case and repair the responsible boundary.
The agent observability guide expands that trace design. A useful threat model does not promise that the model will never be confused; it limits what confusion can cause and makes the resulting behavior visible enough to correct.