> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Guarding AI memory
- URL: https://f4n6.co.uk/security-feed/guarding-ai-memory/
- Published: 2026-06-23T10:34:36.000Z
- Updated: 2026-06-23T10:34:36.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Microsoft has published a defensive architecture blog describing how AI "memory" features in M365 Copilot change the threat model for agentic AI: an attacker can stage a prompt-injection payload across multiple sessions, with the malicious instruction only triggering tool calls days after the original exposure, when user awareness is lower and human-in-the-loop controls are weaker. The blog frames the scenario as hypothetical but states it "reflects patterns observed in real-world research," and credits MSRC cases from Johann Rehberger, Håkon Måløy and Gal Zror. For EMEA financial services firms using M365 Copilot, the bottom-line risk is that a single poisoned document can silently seed persistent attacker-controlled memory, which then drives exfiltration of high-value data (calendar, mailbox-derived content) on every subsequent interaction until the memory is purged. No CVE, no malware sample, and no named threat actor are associated with this advisory; severity is therefore not numerically scored.

## 2\. Regulatory framing

| Article            | Trigger (the fact in this item)                                                                                                                | Practical impact                                                                                                                                          |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 28       | M365 Copilot is an ICT third-party service whose "memory" feature introduces a new concentration and attack-surface consideration for tenants. | Include AI-memory risk in the ICT third-party risk register and reassess concentration risk for any tenant that has enabled Copilot memory.               |
| DORA Art. 30       | Microsoft is the ICT third-party provider; contractual provisions on security and incident handling apply to the memory feature.               | Confirm the Microsoft contractual schedule covers memory-write sanitisation, audit logging (MemoryUpdated) and Customer Lockbox for memory data.          |
| DORA Art. 17       | A successful memory-poisoning incident would be an ICT-related incident requiring a defined management process.                                | Ensure the incident management process covers asynchronous, agent-driven tool calls and delayed exfiltration, not just synchronous user-initiated events. |
| DORA Art. 18       | Memory-poisoning events are a new class of ICT-related incident/cyber threat requiring classification criteria.                                | Add "AI memory poisoning / delayed tool invocation" to the incident classification taxonomy.                                                              |
| DORA Art. 24       | The defensive controls (Task Adherence, prompt-injection classifiers, MemoryUpdated audit) require testing to be effective.                    | Plan resilience-testing scenarios that exercise memory-poisoning paths in non-production tenants.                                                         |
| NIS2 Art. 21(2)(d) | AI memory is a supply-chain component delivered via M365 Copilot that shapes downstream agent behaviour.                                       | Treat Copilot memory as a supply-chain dependency in vendor due diligence and security assessments.                                                       |
| UK NIS 2018        | OES/RDSPs using M365 Copilot inherit the memory attack surface for regulated workloads.                                                        | Confirm OES/RDSP risk assessments and incident playbooks account for AI memory as a data and control plane.                                               |

## 3\. Technical analysis & attack chain

The Microsoft blog describes a **hypothetical** scenario that the publisher states reflects patterns observed in real-world research. The chain below is reproduced from that scenario; it is not a confirmed in-the-wild incident.

1. **Initial access — poisoned content.** A user opens a shared document whose formatting contains hidden instructions (e.g., white-on-white text, hidden layers, metadata fields) addressed to the AI assistant. The instruction is a directive to exfiltrate the user's schedule.
2. **Dormant ingestion.** The assistant processes the document and the hidden payload but takes no immediate tool action. The payload is effectively shelved in the session/context.
3. **Delayed tool invocation (temporal gap).** Days later, in an unrelated conversation, the dormant payload triggers. The assistant invokes the memory tool and writes attacker-defined content into long-term memory.
4. **Memory write.** The poisoned memory entry is stored alongside legitimate user memories. Microsoft's stated defences at this point are: prompt-injection classifiers that strip malicious content on write, and a "Task Adherence" check on every explicit memory write that flags tool invocations misaligned with user intent.
5. **Persistent exfiltration.** On every subsequent relevant interaction, the poisoned memory causes the assistant to update the attacker with the user's schedule (or other targeted data), until the memory is purged.

### Technical specifics that matter to a defender

- **Attack surface change.** Without memory, an attacker must "win" in a single prompt. With memory, the attack can be staged across sessions, and the trigger fires outside the original context where defences and user attention are lower.
- **Asynchrony.** Memory events happen asynchronously from user interactions, breaking traditional human-in-the-loop patterns and complicating forensics.
- **Defence layers Microsoft describes (in-product):**
- *Memory Creation:* proprietary prompt-injection classifiers inspect content on write and strip malicious input; M365 Copilot runs Task Adherence checks on every explicit memory write to detect misaligned tool invocations; tenant-level policy can disable AI-memory personalisation.
- *Memory Storage:* memories inherit M365 data governance — Data Subject Requests (DSR), tenant isolation, Customer Lockbox, encryption at rest — and are treated like mailbox data.
- *Observability:* memory updates are written to organisational audit logs. The `MemoryUpdated` field is surfaced in Defender Advanced Hunting, Microsoft Defender Sentinel, and Azure Portal Sentinel Analytics for SOC triage and alerting.
- **Research attribution.** MSRC cases credited to Johann Rehberger (first finder), Håkon Måløy and Gal Zror. No MITRE-attributed threat actor group is associated with this class of attack in the source material; any actor attribution should be treated as unconfirmed.

## 4\. Mitigation & containment

### P1 — within 24h

- **Inventory exposure.** Identify which M365 Copilot tenants and which user populations have AI memory enabled. Disable AI-memory personalisation at the tenant level where not business-required (tenant-level policy).
- **Audit current memory state.** Use the `MemoryUpdated` field in Defender Advanced Hunting / Sentinel to enumerate recent memory writes and review for anomalous sources or content.
- **Restrict high-risk data flows.** Until governance is confirmed, disable or restrict Copilot's ability to act on calendar/mailbox data derived from memory for users handling regulated data.

### P2 — within 72h

- **Enable and tune observability.** Ensure M365 Copilot audit (including `MemoryUpdated`) is flowing into the SIEM; build alerts on memory writes that follow suspicious document ingestion events.
- **Content-source controls.** Block or warn on documents from untrusted external sources that contain hidden text, hidden layers, or formatting anomalies before they reach Copilot ingestion pipelines.
- **Policy review.** Confirm tenant policy, Customer Lockbox eligibility, and DSR coverage explicitly include AI memory data.

### P3 — within 7 days

- **Tabletop exercise.** Run a scenario exercising delayed tool invocation: poisoned document → dormant → trigger → memory write → exfiltration. Validate detection, response and purge playbooks.
- **User awareness.** Brief users handling sensitive data on the risk of opening untrusted shared documents with Copilot enabled, and on reporting delayed/unsolicited Copilot tool actions.
- **Vendor assurance.** Confirm contractual coverage under DORA Art. 30 for memory-write sanitisation, audit logging and incident handling with Microsoft.

## 5\. Indicators of compromise

No indicators of compromise (file hashes, domains, IPs, registry keys, filenames) are present in the source material. The source describes a behavioural class of attack, not a specific malware sample or campaign.

No indicators of compromise available in the source material.

## 6\. Detection

The source provides a usable behavioural/log artefact: the `MemoryUpdated` audit field in Defender Advanced Hunting, Defender Sentinel and Azure Portal Sentinel Analytics. The Sigma rule below targets memory-write events for triage and correlation with suspicious document ingestion.

```yaml
title: M365 Copilot AI Memory Write Event
id: 8c7f1a2e-3b4d-4e5f-9a6b-7c8d9e0f1a2b
status: experimental
description: |
  Detects M365 Copilot AI memory write/update events for SOC triage and
  correlation with suspicious document ingestion. Based on the
  MemoryUpdated audit field surfaced in Defender Advanced Hunting,
  Defender Sentinel and Azure Portal Sentinel Analytics.
author: Adverse Trace
date: 2026-06-23
references:

  - https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/
logsource:
  product: microsoft365
  service: defender
detection:
  selection:
    eventSource: Microsoft365Copilot
    field: MemoryUpdated
  condition: selection
falsepositives:

  - Legitimate user-initiated memory writes during normal Copilot use
level: informational
tags:

  - attack.initial_access
  - attack.t1059    # placeholder; memory write is not a script execution but used for ATT&CK tagging discipline

```

## 7\. Sources

- Microsoft Security Blog — *Guarding AI memory* — https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/ — 2026-06-22

## 8\. Adverse Trace position

This is an architectural and governance advisory, not a patch-now vulnerability: there is no CVE, no malware sample and no confirmed in-the-wild incident in the source. The risk to EMEA financial services is real but conditional — it requires (a) M365 Copilot with AI memory enabled, (b) users handling documents from untrusted or semi-trusted sources, and (c) high-value data (calendar, mailbox-derived content) reachable by Copilot tool calls. Clients should prioritise tenant-level policy review, audit-log ingestion of `MemoryUpdated`, and a tabletop exercise covering delayed tool invocation before treating this as a P1 incident-response item. Adverse Trace will monitor for any subsequent MSRC advisory, CVE, or named-actor attribution that would move this from "architectural risk" to "active threat," and will update this advisory accordingly.

---

[Read the original source →](https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*