How to Govern Microsoft Foundry Agent Memory in Production Safely

In this blog post How to Govern Microsoft Foundry Agent Memory in Production Safely we will explain how to keep useful AI context from becoming an uncontrolled store of sensitive, inaccurate or outdated information.

The problem often appears after a successful pilot. An agent starts remembering customer preferences, employee details and previous decisions, making it faster and more helpful. Then someone asks a simple question: what exactly has it stored, who can see it, and when will it be deleted?

Microsoft Foundry is a managed platform for building, deploying and monitoring AI applications and agents. An agent combines an AI model with instructions, approved business data and tools that let it complete tasks. Memory adds another layer by allowing the agent to retain selected context between conversations.

Think of memory as the agent’s notebook. The technology can extract useful facts from a conversation, save them as memory items and retrieve the relevant items later. That notebook can improve productivity, but it needs the same controls you would apply to a customer database or employee record system.

Why memory changes the production risk

A demonstration normally involves limited data, a few trusted users and close supervision. Production may involve hundreds of employees, thousands of customers and connections to Microsoft 365, service management platforms, finance systems or customer databases.

A memory mistake can also persist. If an agent incorrectly remembers that a customer approved a contract change, the error may influence future conversations long after the original interaction has ended.

This builds on our broader guide to moving AI agents into production safely with Microsoft Foundry. Here, the focus is narrower: treating memory as governed business data rather than a convenient AI feature.

1. Decide what the agent is allowed to remember

The first control is not technical. It is a clear business decision about which information creates enough value to justify storing it.

An internal service desk agent might remember an employee’s device type, office location and completed troubleshooting steps. It should not remember passwords, multifactor authentication codes, private HR discussions or personal medical information.

Create an approved memory list and a prohibited memory list for every production agent. Tie every approved category to an outcome such as reducing repeat questions, shortening support calls or improving customer continuity.

If nobody can explain why a piece of information needs to be retained, the safest and cheapest option is not to store it.

2. Separate working context from long-term memory

Short-term context helps the agent follow the current conversation. Long-term memory carries selected information into future sessions. These should not be treated as the same thing.

For example, a customer might provide an invoice number so an agent can investigate a current issue. The number may be useful during that conversation, but there may be no reason to retain it as a long-term customer memory.

Foundry memory can extract and consolidate useful details into a managed memory store. It can also retrieve relevant items when the user returns. Our earlier article on how Microsoft Foundry Agent Memory makes AI agents more useful explains this capability in more detail.

The important production rule is that memory should not quietly become the source of truth. Customer status belongs in the customer relationship management system. Employment status belongs in the HR platform. The agent may use approved context, but authoritative records should remain in the system designed to manage them.

3. Scope memory to the correct identity

A useful memory shown to the wrong person becomes a data breach. Every memory therefore needs a clear boundary that determines which user, customer, team or agent can retrieve it.

Microsoft Foundry supports memory scopes, which separate stored context between users or other defined groups. Microsoft Entra ID, Microsoft’s identity and access management service, can then help ensure the person and agent are correctly authenticated.

A finance agent should not retrieve HR memories simply because both agents operate inside the same company. Separate high-risk use cases into their own projects and memory stores, then provide only the minimum access needed.

Apply the same principle to the agent itself. Give it a dedicated identity and tightly limited permissions instead of using a shared administrator account or embedding passwords in code.

4. Set deletion rules before storing anything

Many businesses define what they will collect but never decide when it should disappear. Over time, useful context becomes outdated data, unnecessary cost and additional exposure during a security incident.

Foundry memory provides retention controls, including a default time to live. In plain English, this tells the service when stored memory should expire. Individual memory items can also be inspected, updated or deleted.

At the time of writing, managed memory in Foundry Agent Service remains a preview capability. Production planning should therefore include additional testing, documented limitations and a review process for platform changes.

Your retention policy should answer four questions:

• How long does each category of memory remain useful?
• Who can correct an inaccurate memory?
• How can a user request deletion?
• What happens to memory when an employee leaves or a customer closes an account?

This is especially important under Australian privacy requirements. The Essential Eight, the Australian government’s cybersecurity framework, strengthens areas such as access control, patching and system protection. However, it does not replace privacy, retention and information governance obligations.

5. Turn the policy into enforceable configuration

A policy document is useful, but production controls should not depend on every developer remembering it. Translate the policy into configuration, automated tests and approval rules.

The following example is a plain-English policy blueprint rather than deployable code:

{
 "agent": "Service Desk Assistant",
 "approvedMemory": [
 "device type",
 "office location",
 "completed troubleshooting steps"
 ],
 "prohibitedMemory": [
 "passwords",
 "MFA codes",
 "medical information",
 "payment card details"
 ],
 "scope": "one authenticated user",
 "defaultRetentionDays": 90,
 "deletionTargetHours": 24,
 "owner": "Head of IT Operations"
}

This gives developers, security teams and business owners a shared definition of acceptable behaviour. It also makes reviews faster because the organisation can compare the running agent against an agreed standard.

6. Monitor what memory is doing to the agent

Traditional monitoring asks whether a system is online. AI monitoring must also ask whether the system is behaving correctly.

Track memory creation, retrieval, correction and deletion. Test whether one user can access another user’s context, whether prohibited information is being retained and whether old memories are producing incorrect answers.

Foundry supports tracing and evaluation, which help teams examine how an agent reached an outcome and which tools or context it used. Logging must also be designed carefully so sensitive information is not removed from memory only to remain indefinitely in diagnostic records.

Microsoft Defender, which identifies threats across Microsoft environments, and Wiz, a cloud security platform that highlights risky configurations and exposed data paths, can add broader visibility around the Azure environment hosting the agent.

A practical production scenario

Consider a 200-person professional services firm introducing an internal support agent. During the pilot, employees appreciate that it remembers their laptop model, location and previous support steps.

Before launch, the company discovers that the agent is also retaining copied email content and details from security incidents. Some memories have no expiry date, and there is no process for removing records when employees leave.

The organisation limits memory to approved support facts, creates a 90-day default retention period and blocks credentials and email content from long-term storage. It also scopes memory to each authenticated employee and sends security-related conversations to a human analyst.

The agent remains useful, but the business avoids building a second, poorly governed employee database. Support staff save time without creating an unnecessary privacy and compliance burden.

Five questions to ask before launch

1. Can we list every type of information the agent is permitted to remember?
2. Can users view, correct and delete information associated with them?
3. Are memory boundaries tested using different roles and accounts?
4. Do retention periods match a documented business purpose?
5. Can we investigate who stored, changed, retrieved or deleted a memory?

If any answer is unclear, the agent is probably not ready for unrestricted production use.

Useful memory needs visible ownership

Memory can make AI agents faster, more consistent and less frustrating. The business outcome can be significant: fewer repeated questions, shorter handling times and better continuity across customer and employee interactions.

Those gains depend on firm boundaries. Give each agent an owner, define what it can remember, separate users correctly, automate retention and continuously test whether stored context is improving decisions rather than distorting them.

For implementation detail, see our guide to securing long-term memory in Microsoft Foundry Agents. Organisations comparing design options may also find our article on choosing the right memory strategy for a reliable OpenAI agent useful.

CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations across Australia and internationally design practical controls spanning Foundry, Azure, Microsoft 365, Defender, Wiz, OpenAI and Claude.

If you are not sure what your production agents are retaining, or whether current memory controls meet your security and privacy requirements, we are happy to take a practical look with you — no strings attached.