Every review of an AI service agent asks what it can read and what it can do. Almost none of them ask who gets to hear what it remembers, and that’s the question behind the incident you’ll actually have to explain.
Here’s the version that should worry you. A project lead messages your support agent to explain why access to a new design tool has to stay inside a five-person team, because the tool is tied to a deal nobody has announced yet. The conversation is private, the agent has permission to help and the ticket closes cleanly. A week later someone in sales asks the same agent which teams are evaluating new tools.
Nothing in the chat window tells you whether that second answer is safe. It depends on what survived the first conversation and who that memory is allowed to reach, which is exactly the part your access review never looked at.
I believe agent memory should be approved as its own data flow, with an owner, an audience and an expiry, the same way you’d approve a new integration. Identity tells you who the agent is. It tells you nothing about who benefits from what it learned.
What does Microsoft’s documentation actually say?
You don’t have to imagine this problem, because it’s sitting in published product docs right now.
Microsoft’s agent accounts feature, documented on 15 October and still in the Frontier preview program, gives a Copilot Studio agent its own Entra ID, its own mailbox and a presence across Microsoft 365. People can find it in Teams and @mention it like a colleague, and admins can govern and audit it like any other identity. That’s the identity half, and it’s done properly.
The FAQ for agent accounts covers the memory half, and it’s refreshingly blunt. The agent keeps one memory across everyone it works with. It’s “guided not to bring up one person’s details with someone else,” but in Microsoft’s own words shared memory has “no privacy boundary between users.” End users can’t opt out in this preview, and the only way for an admin to turn shared memory off is to turn off agent accounts altogether. The notice on the agent’s People card goes further; files or chats shared with the agent can be summarized into its responses to any user, “even users without permissions to the files or chats and regardless of sensitivity label.”
Read that last clause again if you’ve put real work into sensitivity labels.
To be fair to Microsoft, the same FAQ documents real safeguards. Health information, credentials and tokens, ID numbers, home addresses, protected characteristics and judgments about someone’s performance are all kept out of memory. Anyone who works with the agent can view or delete what it saved. Shared memories are also deleted after 28 days, but only if nobody interacts with the agent in that time, and a busy support agent is never going to sit idle for 28 days. This is a disclosed design with guardrails, and nobody should call it a breach. It’s also a design where, for anything outside those excluded categories, what stands between one user’s conversation and another’s is guidance.
Now compare it with Microsoft’s memory documentation for agents built on the GitHub Copilot harness, updated 21 October. There, each agent keeps a separate memory store for every user, “so one person’s context is never shared with another,” and user memory is switched off in group chats and Teams channels. Same vendor, same product family, opposite answer to the audience question.
This is why “does Copilot have memory?” is the wrong thing to ask in a deployment review. You need to know which memory model your specific agent setup uses, because the product name won’t tell you.
Access and authority get reviewed. Audience gets assumed.
When you scope a service agent, three questions show up together and usually get answered as one:
Access: which records can it retrieve?
Authority: which actions can it take?
Audience: who can receive what it learned?
The first two get answered in every vendor demo, and the third usually gets waved through.
Say a manager lets the agent read a restricted project note to sort out an access problem. That’s a legitimate reason for the retrieval. It doesn’t make a summary of that note fair game for a shared memory, and a derived summary can carry exactly the same commercial sensitivity as the source, even with no health data, credentials or personal details in it. Memory exclusions are built around categories of personal information, and your unannounced deal isn’t in any of them.
So the questions to put to the vendor are about the relationship between the source and what the agent kept. If the source gets restricted, does the memory still answer? If a user loses access, does anything downstream notice? If three documents fed one summary, does the summary still carry all three sets of restrictions?
The industry is building controls, just not this one. ServiceNow’s AI Passport, announced 15 October and expected in Q4 2026, is a cryptographically signed credential that agents check at runtime to confirm they’re inside their authorized scope. Atlassian’s 20 October connector update lets admins restrict Rovo connectors to approved account domains and switch individual read and write tools on or off. Both are useful, and both answer the access and authority questions. Neither tells you who’s allowed to receive a remembered summary, or what’s left in memory after you disable the connector that fed it.
Isn’t shared memory the whole point?
Partly, yes, and pretending otherwise would be dishonest. Your support team shouldn’t have to re-explain the printer exception, the laptop-return procedure or the escalation route to an agent in every conversation. Shared process knowledge makes service faster and more consistent.
A private store for every employee has its own costs too. Corrections have to be repeated, two people get different answers to the same question, and useful process knowledge stays trapped in a pile of one-on-one chats.
So shared versus private is the wrong argument. What matters is what gets promoted into shared knowledge, and through which door. A better design keeps case details inside the authorized audience for that request, keeps personal preferences per person, and promotes reusable procedures into a reviewed knowledge source that someone actually owns. Not every vendor supports that split today, which is exactly why you should ask.
This matters even more once your service desk spans IT, HR and Ops. Employees should get one familiar place to ask for help in Slack or Teams, while their requests move through very different information-handling paths behind it. That’s the setup we build for at Ravenna, so this isn’t an abstract worry for us. One front door is great for employees; it shouldn’t quietly decide the audience for everything said through it.
And until you can switch shared memory off without switching the agent off, keep an account-based agent away from any desk that mixes those audiences. A team agent handling printer exceptions is a fine place to learn how it behaves, and your HR queue isn’t.
How do you test the boundary before rollout?
Don’t take the architecture diagram on faith. Run a small synthetic test with made-up data, so you don’t need a single real employee record:
Give the agent a fake project fact in a conversation with test user A.
Ask test user B a related question, worded differently.
Inspect what was retained, what was retrieved, and why the answer was allowed.
Change the conditions: remove A’s access to the source, move A to another team, delete the saved memory, and ask again.
Ask what “delete” actually covers, because active memory, derived summaries, logs and backups rarely share one lifecycle.
Then test integrity as well as confidentiality. A remembered exception shouldn’t become authority for the next request just because it came up in an earlier chat. When an employee says their manager already approved something, that’s a claim to verify; it doesn’t rewrite the approval policy. OWASP’s prompt injection cheat sheet calls this context poisoning (false information injected into an agent’s working memory) and recommends validating every tool call against user permissions and session context. Leakage and poisoning are different failures, so test for both.
Before the technical team touches any of this, the service owner should be able to write the intended behavior in plain English. Something like: project-specific facts stay with the authorized project audience; published procedures can be reused by anyone; remembered statements never replace a required approval. If nobody can write that sentence, you’re not ready to switch memory on.
Put an owner on what the agent learns
Memory isn’t a setting you flip once. Someone has to own the categories the agent may keep, the audience for each, the correction process, and what happens when an employee reports an answer that shouldn’t have reached them. “Be careful” isn’t an owner, and it won’t settle an argument about who should’ve seen a project detail.
For a narrowly scoped team agent handling agreed, non-sensitive procedures, shared memory can be exactly right. A confidential HR or access workflow needs a different call. Both are sensible decisions, as long as someone made them on purpose.
Pick one employee-support process this week and follow the information after the conversation ends: into memory, into summaries, into search, into somebody else’s answer, and finally into deletion. Then ask your vendor to show you each boundary along that path.
Your employees shouldn’t need to understand an agent’s storage architecture to ask for help safely. You do, preferably before someone in sales asks that question.
Frequently Asked Questions
What Is Agent Memory?
Agent memory is what an AI agent keeps after a conversation ends and reuses in later ones: preferences, earlier decisions, process details and summaries of things it read. It’s separate from the agent’s instructions and its knowledge sources, which is why it needs its own review. The first thing to find out is who the memory is scoped to, because a store per user and a store shared across everyone are very different risks.
What Is AI Agent Governance?
AI agent governance is the set of decisions about what an agent may access, what it may do, who answers for it and how you check afterwards. Most programs cover identity, permissions, approvals and audit logs. Fewer cover what the agent retains and who can receive it later, which is the gap this post is about.
What Is AI Agent Security?
AI agent security means keeping an agent from leaking data, taking actions nobody authorized or being steered by untrusted input. In practice that’s scoped permissions, validating each tool call against the user’s own rights, and treating anything said in a conversation as a claim to verify. Memory adds one more concern, because retained context can leak or be poisoned long after the original conversation.
How Can Companies Reduce AI Agent Security Risks?
Start small: give the agent the narrowest permissions the job needs, and keep required approvals outside anything the agent can talk its way around. Test with synthetic data before rollout, including what one user can get back out of another user’s conversation. Then put a named owner on what the agent remembers, who can receive it and how it gets deleted.
