Copilot records, retention and FOI: an agency checklist

In November 2025, a freedom of information request produced something no Australian agency had released before: roughly 50 documents of Microsoft 365 Copilot prompts and responses belonging to the Department of Home Affairs' head of national security, covering a two-month period. The logs, reported by Startup Daily, showed the assistant drafting analytical notes, speech material and internal messages that were later edited and used as delivered work. Nobody leaked anything. The prompts were agency documents, someone asked for them, and out they came.

That release settled a question many agencies had been treating as open. Copilot prompts and responses are records, they are discoverable, and they can be requested under FOI like any other document an agency holds. The Digital Transformation Agency's evaluation of the whole-of-government Copilot trial had already flagged the problem from the other direction: uncertainty about whether FOI applied to Copilot use, and about the need to disclose that use, was one of the barriers holding staff back, particularly around meeting transcription. The uncertainty is resolvable. What it takes is treating Copilot content as a records-management surface before enablement, not after the first FOI request lands.

This guide covers where Copilot interactions physically live, how Microsoft Purview retention applies to them, what eDiscovery and legal hold can and cannot reach, the FOI and state records obligations that attach to them, and a records-readiness checklist for an agency or council preparing to enable Copilot. It is a companion to Frontrow's broader guide at /insights/copilot-for-government-australia, which covers the full deployment picture for the public sector.

Where Copilot interactions actually live

The recordkeeping conversation gets easier once the storage model is clear. When a user prompts Microsoft 365 Copilot and receives a response, that interaction is stored as message data in the user's own Exchange Online mailbox, in a location hidden from normal mailbox views. It is not a separate Copilot database, and it is not ephemeral. Because it sits in the mailbox, it inherits the mailbox's compliance machinery: retention, eDiscovery search, and legal hold.

In Microsoft Purview, retention for this content runs through a dedicated policy location called Microsoft Copilot experiences, which Microsoft split out from the older combined Teams chats and Copilot interactions location. A retention policy that includes this location governs user prompts and responses for Microsoft 365 Copilot and Copilot Studio, and can be scoped to the whole organisation or to selected users through adaptive scopes.

Two adjacent surfaces are easy to miss. Teams meeting transcripts, which Copilot's meeting summaries are generated from, are governed separately from the Copilot interaction itself, and were the single biggest source of FOI unease in the DTA trial. And Copilot Pages, the persistent canvas where users keep and edit Copilot output, are stored in SharePoint Embedded containers rather than the mailbox, which matters for holds, as covered below.

How retention policies apply to prompts and responses

The mechanics are the same as mailbox retention. A retention policy on the Microsoft Copilot experiences location can retain Copilot interactions for a defined period, delete them at the end of it, or both. If no policy covers the location, the content simply persists with the mailbox and follows the mailbox's lifecycle, which for most tenants means it accumulates indefinitely while the account exists.

The common misconfiguration is assuming existing policies already cover this. A tenant that carefully built retention for Exchange email, SharePoint and Teams before Copilot existed has not necessarily said anything about Copilot interactions, because they are a distinct location that has to be included deliberately. An agency with a records authority requiring, say, seven-year retention of significant business communications needs to decide where Copilot interactions sit in that scheme and configure the location to match.

• Decide the retention class first. Are Copilot interactions transitory working papers, or substantive records? For most agencies the honest answer is that some are each, which argues for a retain-then-review posture rather than aggressive early deletion.
• Do not default to short deletion to reduce FOI exposure. Destroying records to frustrate access obligations is itself a breach of records law in every Australian jurisdiction, and a deletion policy adopted after a request arrives is far worse than one adopted deliberately beforehand.
• Check the interaction between retention and departing staff. When a mailbox is deleted, Copilot interactions go with it unless a retention policy or hold preserves them, exactly as with email.
• Remember Copilot Studio agents. Purview retention for AI apps reaches Copilot Studio prompts and responses too, and a council that builds a resident-facing agent has created a new record series whether or not anyone has classified it.

eDiscovery and legal hold on Copilot content

Because interactions live in the mailbox, Purview eDiscovery treats them as searchable content. A case manager can search, preserve, review and export Copilot prompts and responses by targeting the relevant user mailboxes, and a hold applied to a custodian's mailbox preserves their Copilot interactions along with their email. Microsoft documents the workflow for searching and, where authorised, deleting Copilot data, with deletion gated behind the Search And Purge role rather than ordinary admin rights.

The practical trap is scope. A hold on the mailbox does not automatically reach Copilot Pages, because Pages live in SharePoint Embedded storage; preserving them means including that user's Pages storage location in the hold as well. For an agency facing litigation, a royal commission or an integrity investigation, discovering that half the relevant Copilot output sat outside the hold is not a conversation anyone wants to have with counsel. Legal and records teams should rehearse this before Copilot is enabled, the same way they once had to rehearse Teams chat discovery.

FOI and state records obligations

At the Commonwealth level, Copilot prompts and responses held in an agency tenant are documents of the agency for FOI purposes, subject to the same exemptions and the same processing obligations as anything else. The National Archives of Australia's advice on records created using AI technologies takes the same position from the records side: content generated with AI tools in the course of agency business is a Commonwealth record and must be managed as one. An agency cannot process what it cannot find, which is why the retention and eDiscovery plumbing above is the real FOI-readiness work.

The states run parallel regimes, and two are worth naming because their guidance is current and specific. State Records NSW treats information created, managed and stored in Microsoft 365 as State records under the State Records Act 1998, and publishes dedicated guidance on configuring M365 to meet the Standard on Records Management, including strategies ranging from in-place management with Purview through to capture into an EDRMS. A NSW council enabling Copilot is extending that same obligation to a new content type, and should be able to show which strategy covers it.

Queensland State Archives is blunter again. Its advice on artificial intelligence and public records states that generative AI systems are not recordkeeping systems, that prompts, responses and conversations can themselves be public records under the Public Records Act 2023, and that authorities need to capture them into their existing recordkeeping arrangements and link AI-generated content to the final official document so the record is complete. For a Queensland authority, 'we enabled Copilot and left records to sort itself out' is a documented non-compliance, not a grey area.

The records-readiness checklist before enabling Copilot

Frontrow runs this as a short, sequenced piece of work before the first Copilot licence is assigned in an agency or council tenant. None of it is exotic; all of it is easier before enablement than after.

1. 1Confirm where Copilot content will live in your tenant: user mailboxes for interactions, SharePoint Embedded for Copilot Pages, and the meeting transcript locations for Teams. Write it down; this map is the answer to the first FOI request.
2. 2Classify Copilot interactions against your records authority. Decide the default retention class, and whether specific cohorts (executive, ministerial liaison, legal) need a longer class.
3. 3Create or extend a Purview retention policy that explicitly includes the Microsoft Copilot experiences location, scoped and labelled so a records manager can explain it.
4. 4Test eDiscovery end to end: run a search for a pilot user's Copilot interactions, place and verify a hold, and confirm Pages storage is included in the hold scope.
5. 5Confirm Purview audit is capturing Copilot events at the retention tier your jurisdiction requires, so use of the tool is itself evidenced.
6. 6Update the FOI procedure so 'documents' searches include Copilot locations, and brief the FOI team on how to request that search from IT.
7. 7Update the agency's AI acceptable-use guidance to say plainly that prompts and responses are records and may be released under FOI. The Home Affairs release is the case study; staff who know their prompts are disclosable write better prompts.
8. 8For NSW and Queensland bodies, map the above against the State Records NSW M365 guidance and the QSA AI advice respectively, and file the mapping as evidence of compliance.

One adjacent risk deserves its own pass: Copilot answers from whatever the user can already reach, so overshared SharePoint content becomes overshared Copilot output, and potentially an overshared record. Frontrow's oversharing assessment below is the fastest way to gauge that exposure.