Data, Memory, and Context Integrity
Provenance labeling, instruction and data separation, and memory writes treated as authorized events.
Objective
Prevent untrusted content from becoming instructions, and prevent poisoned state from persisting.
Minimum bar (L2). Retrieval scoped to what the invoking principal is entitled to see, enforced at the data layer rather than by filtering after retrieval. Memory has a defined retention period. Sensitive data classes are excluded from context by policy.
11.1 Controls #
| ID | Control | Minimum bar (L2) | Enforced state (L3) |
|---|---|---|---|
| DATA-1 | Provenance labeling | The source of every element placed in context is recorded at assembly time, and content originating outside the trust boundary is distinguishable from content the organization controls. The distinction may inform logging and review rather than runtime enforcement, but it exists and is queryable after an incident. | Provenance labeling: every element in context is tagged with its source and trust level, and the orchestrator enforces that low-trust content cannot alter the agent’s objective or tool authorization. |
| DATA-2 | Instruction and data separation | Retrieved content, tool outputs, and inter-agent messages are delimited and marked as data during context assembly, and system instructions cannot be constructed from retrieved content. Where the architecture cannot enforce the separation, the residual risk is documented rather than assumed away. | Structural separation between instruction channels and data channels, to the degree the architecture permits—and explicit acknowledgment where it does not. |
| DATA-3 | Memory writes as authorized events | What an agent may persist is defined by policy per agent—categories permitted, categories prohibited—with retention limits applied. Memory writes are logged even where they are not individually authorized at runtime. | Memory writes are authorized events, subject to the same policy engine as tool calls. Not everything an agent learns should persist. |
| DATA-4 | Session isolation | Context and cached retrieval are scoped to a single principal and cleared at session end. Multi-tenant agents are tested for cross-tenant bleed before production, and the test is repeated on material change to the retrieval or memory architecture. | Session isolation: cached context wiped between tasks and between principals. No cross-tenant or cross-user memory bleed. |
| DATA-5 | Output filtering | Responses crossing the trust boundary pass a filter for credentials, secrets, and regulated data classes, with defined handling on a hit. Coverage is documented per egress path, including tool outputs and inter-agent messages, not only end-user responses. | Output filtering for credentials, secrets, and regulated data before responses leave the boundary. |
| DATA-6 | Memory integrity checks | Memory and vector stores are inventoried, with write access restricted to identified principals and a named owner accountable for corpus content. Adversarial retrieval testing using poisoned documents is performed before production and repeated after material change to the corpus. | Periodic integrity checks against memory and vector stores for injected content. |
11.2 Evidence to Request #
- A retrieval trace showing entitlement enforcement at the data layer.
- Memory retention configuration.
- Results of an adversarial retrieval test using poisoned documents.
11.3 Failure Modes #
- Entitlement filtering applied after retrieval, so the sensitive content transited the model before being removed.
- Long-lived memory treated as a feature with no security review, becoming a persistent injection foothold.
- Prompt injection treated as a solved problem because a filter was added. It is a property of the architecture; filters reduce frequency, not category.