AIG-056 Agent Memory and Context Integrity
Description
Durable state an AI agent reads or writes across tasks or sessions, including saved preferences, conversation summaries, stored history, episodic or semantic memories and agent-managed experience stores, is held in a store with a documented boundary. Every read and write to the store is authenticated and authorised within the user, tenant, agent and session scope of the request. Entries are segregated by user session and by domain context so that neither knowledge nor sensitive data crosses between them. A memory policy states, for each class of entry, the limit on entry size and update frequency, the retention period and deletion rule and the classes of source a write is accepted from. A write is validated against the policy before it is committed. Output the agent itself produced enters a trusted class of memory only through the same validation as external content. Each entry records its source, the time it was written and the agent or pipeline that wrote it. A version history of the store is kept so that it can be returned to a known good state. An entry whose source cannot be verified expires within the period the policy sets. An entry suspected of poisoning is quarantined or rolled back with the action recorded. Retrieval ranks or filters entries by their trust tier, so that an entry which would inform an action classified as consequential carries verified provenance or a human-verified mark before it is used. Security-relevant memory reads and writes are logged. An unusual update frequency or a run of repeated self-authored updates raises an alert to the person the monitoring plan names.
Rationale
An agent that keeps state between runs carries every earlier run forward, so a single poisoned entry becomes a standing influence on what the agent does next rather than a one-off bad output. Four neighbours answer different questions. INF-015 holds the tenant boundary and the vector index built from ingested corpus content; this control holds the state the agent writes for itself at run time; a memory store that serves several tenants sits inside the INF-015 boundary as well. AIG-042 governs what the agent may do; this control governs what it may remember and whether that memory can be trusted. AIG-029 tests the injection route by which a poisoned entry usually arrives; this control bounds the integrity of the store once something has arrived. AIG-026 evaluates poisoning of training data and model artefacts; runtime memory is a different surface with a different owner. DAT-008 holds the retention schedule the memory policy's periods are drawn from and AIG-020 is the AI event log the memory operation log belongs in. The trust tier on an entry follows the trust tier of its source, which INF-015 already requires a corpus entry to carry. Both seats (ADR-031): a deployer running agents on a provider's runtime holds the policy and the review of its own entries and the provider's runtime enforces the scope.
Applicability (9 profiles)
The memory policy, the review of its own entries and the response to a suspected poisoning are the deployer's for agents it runs against its own systems and data. Where the agent runtime and its memory store are the provider's, the scope enforcement, the validation before commit and the version history are provider features and the deployer configures them and records that it has (AIG-034 instructions for use).
The memory policy, the review of its own entries and the response to a suspected poisoning are the deployer's for agents it runs against its own systems and data. Where the agent runtime and its memory store are the provider's, the scope enforcement, the validation before commit and the version history are provider features and the deployer configures them and records that it has (AIG-034 instructions for use).
Framework Mappings (4)
| AML.M0031 | Memory Hardening | full |
| AML.M0032 | Segmentation of AI Agent Components | informative |
| ASI06 | Memory & Context Poisoning | full |
| LLM09 | Vector and Embedding Weaknesses | informative |
Evidence (3)
The access control and policy limits of the agent memory store as configured, read from the running system or from the infrastructure code that defines it: the scope checks applied to reads and writes, the segmentation by session and domain context, the size, frequency and expiry limits per entry class, the validation applied before a write commits and the snapshot or version history that supports rollback.
Example: Memory service configuration under infra/agents/memory/ at commit 4e2d91c, with the runtime policy listing fetched from the memory service on 8 September 2026.
Test: Verify: (1) a write or read presented with a session, tenant, agent or user scope other than the entry's own is refused, (2) the size, update-frequency and expiry limits enforced at runtime match the memory policy for each entry class, (3) an entry written from an unverified source and older than its expiry period is no longer readable, (4) output the agent produced and wrote to a trusted class was routed through the same validation as external content, shown by the validation record on the entry, (5) a rollback to a named prior version restores the store to that version and the rollback is recorded, (6) retrieval for a consequential action excludes or flags entries below the trust tier the policy sets.
Memory operation log carrying, for each security-relevant read and write, the entry, the scope of the request, the identity of the agent or pipeline that made it, the source recorded on the entry, the validation outcome and, for a quarantine or rollback, the action taken and who took it, together with the alerts raised on unusual update frequency or repeated self-authored updates.
Example: Memory service audit log for 1 to 31 August 2026, queried for the customer-support and procurement agents, with the alert history for the same period.
Test: Verify: (1) every write in the sample carries the source, the time, the writer identity, the request scope and the validation outcome, (2) every entry marked quarantined or rolled back has a recorded action and actor, (3) a synthetic burst of self-authored updates injected in a test window raised an alert to the person the monitoring plan names, (4) no read in the sample returned an entry whose expiry had passed, (5) alerts in the period carry a triage record with an outcome.
The agent memory policy: the classes of entry the store holds, the limit on entry size and update frequency per class, the retention period and deletion rule per class, the classes of source a write is accepted from, the validation applied before commit, the trust tiers and what each permits at retrieval and the quarantine and rollback procedure with the roles that may invoke it.
Example: Agent memory policy version 1.2, approved 15 July 2026.
Test: Verify: (1) every class of entry the running store holds appears in the policy with a size limit, an update-frequency limit and a retention period, (2) the retention periods trace to the schedule DAT-008 requires, (3) the accepted source classes are named and the agent's own output is not a trusted source without validation, (4) the quarantine and rollback procedure names who may invoke it and how the action is recorded, (5) the policy was approved and reviewed within the interval it states.
Questions (3)
Are reads and writes to the durable memory your AI agents keep between tasks authorised within the user, tenant, agent and session scope of the request?
Durable memory is any state an agent reads or writes across tasks or sessions: saved preferences, conversation summaries, stored history, episodic or semantic memories and agent-managed experience stores. A store that any agent or session can read or write in full is not scoped. Where no agent keeps state between tasks, this control does not apply to you.
Which of the following are in place for agent memory?
Options follow the lifecycle from policy to write, from write to retrieval and from retrieval to recovery. The self-authored output item asks whether an agent can promote its own conclusions into memory it will later trust without a check; that is the loop a poisoned entry reinforces itself through.
What happens when an entry in agent memory is suspected of being poisoned?
Options run from the strongest response to the weakest. Answer for the procedure that has actually been used or tested, not for a capability the store could offer.