When Content, Authority, and Intent Diverge

Cloudflare's security-audit skill treats AI, LLM, agent, and MCP systems as a special case of the same boundary problem: untrusted content can influence a model, the model can select a capability, and that capability may act under an identity the content does not possess. This chapter applies the invariant method to that chain, showing why prompt injection alone is not a finding and why authorization, execution identity, and user intent must be checked separately.

The central difficulty is that several kinds of input meet in one context. A retrieved document may be attacker-controlled. A memory record may have been written by a lower-trust user. A model response may be generated rather than authenticated. A tool description or MCP schema may look authoritative while arriving from a peer that has not been bound to the trusted connection. Treating all of those inputs as instructions is a design failure, but merely calling them “untrusted” is not yet a vulnerability. The audit must show what deterministic decision or side effect they influence.

A model context is not a security boundary

A language model can read text without that text gaining authority. The first question is therefore not “can an attacker inject a sentence?” It is “what can the injected content cause the system to do that the attacker could not do directly?”

Consider a retrieval system that indexes documents supplied by users. A document may contain language aimed at a later assistant: reveal private records, ignore the current task, or call a tool. That text becomes a security finding only if the surrounding code lets it cross a boundary. The reviewer must identify who can write the document, which tenant or resource scope the retrieval query uses, whose session consumes the result, and which capability becomes reachable. If the document is shown only to the author in the author's own session, the text may be adversarial but it has not demonstrated cross-principal impact.

The same logic applies to persistent memory. A low-trust actor may be able to write a preference, summary, observation, or note. The audit follows that write to a later read. Does the memory enter another user's context? Does it shape a privileged task? Does the retrieval path distinguish user preferences from tool policy? Can the original writer update, merge, or delete the record? A shared memory table is not enough by itself. The claim needs both the attacker-controlled write and a reachable consumer whose authority or data scope is different.

Memory also creates a lifecycle problem. A record may be safe when it is stored under one user's session but dangerous after a merge, account switch, role change, or cache reuse. A deletion or correction may update the primary memory store while leaving an embedding, prompt cache, summary, or queued retrieval job available to another session. The reviewer follows the record's provenance and scope across creation, retrieval, update, invalidation, and deletion. This is the same derived-copy reasoning used for ordinary data systems, with the additional complication that a model may treat an old observation as a current instruction unless the application preserves its type and origin.

Prompt role and provenance are part of this path.