AI Agent Deprovisioning: Revoking Access Does Not Erase What the Agent Remembered

Published 28 October 2026 by Gaurav Dadhich. Every source below was read on 28 October 2026.

Revoking an AI agent's access stops its next read and does nothing to its last one. When you revoke an OAuth token, remove a tool permission, set a user to active: false over SCIM or retire the agent outright, every fact the agent already pulled into memory stays where it was written: the extracted fact, the embedding, the conversation summary, the cached tool result and the line in a shared team profile. RFC 7009, the OAuth token revocation standard, promises that a revoked token "cannot be used again after the revocation". It says nothing about the data that token already moved, and an agent with memory exists to move data out of the systems it reads and into a store that is almost never indexed by the credential that fetched it.

A deprovisioning checklist for an agent with memory therefore needs five things a credential checklist does not have: memory scoped to the credential or connection it came through; provenance on every memory, summaries and consolidated records included, linking it to its source and to the permission that allowed the read; a permission check at read time, so a revoked grant stops answering before any cleanup runs; a purge that fires on the revocation event and follows provenance into derived memory; and an audit record of what was read, what was purged and what was kept on purpose. Most of it must exist before the first write. A fact stored without its source cannot be removed selectively later, however good the purge job is.

Why does revoking an AI agent's access not delete its memory?

Revocation acts on credentials, and memory is data. RFC 7009 says a revocation request "will invalidate the actual token and, if applicable, other tokens based on the same authorization grant and the authorization grant itself," and that the invalidation "takes place immediately". Its security considerations add that the specification does not intend to provide countermeasures against token theft and abuse. Nothing in the standard reaches into the client to remove what the token fetched.

For a classic SaaS integration the gap was mostly invisible, because the integration rendered data on request and went blank when the token died. An agent with memory inverts that shape. WorkOS put it precisely on 19 October 2026: agent context "is a copy of your data, not a view of it." Its example is OpenAI's safety page for dots, which WorkOS quotes as saying that disconnecting an app "stops new information sharing through that connection. But information a dot has already learned remains in its own context." OpenAI documents a context reset, and that reset sits in the dot user's account, not with the company whose data the dot read.

Your own stack behaves the same way, with the difference that you hold the controls. A memory pipeline extracts facts from conversations and tool results, embeds them, summarises them and, in many designs, consolidates them overnight. Each step writes a new record, and none of those records carries the OAuth token. When the token is revoked, the records stay.

What stays readable after you revoke an agent's access?

Embeddings deserve a direct answer, because teams sometimes treat them as anonymous. Morris and co-authors recovered 92% of 32-token text inputs exactly from their embeddings, and recovered full names from a dataset of clinical notes. An embedding of a document read through a revoked grant is a copy of that document in another encoding, and it belongs in the purge.

Consolidation is the quieter problem. AWS's 4 September 2026 guide to lifecycle policies for AgentCore memory merges low-scoring memories through an LLM, stores the consolidated memory and "then deletes the originals". As a cost control that is reasonable, and AWS says plainly that "consolidation is lossy by nature." Unless the consolidated record copies forward the source and permission of every original it absorbed, a later revocation has no way to find which merged memory carries data from the revoked source. Our vector database comparison makes the same point about deletes: removing the vectors that carry an ID leaves every summary and profile that was derived from them.

Which revocation are you handling?

Published offboarding guides mostly treat agent offboarding as one event: the agent is retired, so revoke its credentials and delete its stores. Roval's seven-step decommissioning protocol, Kovrr's decommissioning guide and the NHI Management Group's leaver analysis handle that event well, and for it "purge the vector store" is the right instruction. It is also the only one of the three revocation events where deleting everything is correct.

The second and third events happen whenever a contractor's engagement ends, someone changes team, a folder is unshared, a role is removed or a connector is disconnected. Memory about the departing person is mostly an erasure and privacy question. Memory learned through their credentials, such as facts the agent read from their Drive, their inbox or their CRM view, is the deprovisioning question, and deleting by user ID does not find it unless every memory recorded whose credential fetched its source.

Memory vendors are starting to close the connection side. Hindsight Cloud's 27 October 2026 update says that when someone leaves the organisation or loses the role that let them connect, "their connections are revoked rather than quietly continuing to work." That is the right default for connections. The update does not say what happens to what those connections already wrote into the memory bank, which is the question to put to any memory vendor, us included.

Is this not the same as an employee remembering what they read?

Partly, and the honest version of the objection deserves its due. People keep what they read, and offboarding has always been partly a legal instrument: an NDA, an acceptable use policy and the expectation that nobody exports the CRM on the way out. WorkOS concedes this and then shows where the analogy breaks, on accumulation (background work keeps reading right up to the moment access is cut) and on sideways spread to delegated agents.

Shared memory breaks it further. A departing employee's memory does not answer their replacement's questions, and a team agent's memory does. Suppose a team agent read a confidential folder through Priya's delegated credential and wrote "the Q3 renewal for the Acme account is at risk over pricing" into team-scope memory. After Priya's access is revoked, Sam, who never had access to that folder, asks the team agent and gets the answer. Retention has turned into privilege transfer: the revoked permission now works for someone who never held it.

The agent memory offboarding checklist

1. Scope memory to the credential it came through

At write time, every memory records two scopes: whose memory it is (the user, team, tenant or agent it serves) and which connection, grant or credential the source was read through, with the principal it acted for. Memory learned through a user's delegated credential defaults to that user's scope. Promoting it into team or tenant memory is an explicit decision, logged as such, and it carries the source permission with it so a reader without that permission does not see it.

Keep credentials themselves out of memory. WorkOS recommends keeping the credential out of the agent's context so that a revoked grant cannot be replayed from the copy, and the same rule applies to anything a memory pipeline might extract from a tool result or a pasted config file.

2. Record provenance on every memory, derived ones included

A memory that can be purged on revocation carries enough to be found by revocation. In practice that is a record like this:

{
  "memory_id": "mem_7f3a",
  "text": "Q3 renewal for the Acme account is at risk over pricing",
  "scope": {"tenant": "t_42", "team": "sales-west"},
  "source": {"system": "google_drive", "object_id": "file_19c", "parent_id": "folder_deals"},
  "via": {"connection_id": "conn_88", "grant_id": "grant_5d1", "principal": "user_priya"},
  "read_at": "2026-10-02T09:14:00Z",
  "derived_from": ["mem_51b0", "mem_51b4"]
}

The via block answers "which revocation should remove this". The source.parent_id lets a read-time check ask one question per folder or collection instead of one per memory. The derived_from list is what makes summaries and consolidations purgeable. A derived memory inherits the provenance of every parent, and the most restrictive permission among them governs who can read it. When a parent's grant is revoked, the derived memory is either regenerated from the parents that remain or deleted; it is never left in place because it "only summarises".

Where you control the tools the agent calls, store references instead of full records. WorkOS's example is a list tool that returns deal_8831 with a one-line summary and a get_deal tool for the detail, so the full record is fetched under an authorization check at call time and the next read after revocation fails, "which is what you thought revocation did all along." The memory keeps the handle and a short description, and the sensitive fields never land in the store.

3. Check permission at read time, not only at write time

A purge takes time to run; a read-time check works on the next query. WorkOS's 12 October 2026 comparison of RAG access control lays out three patterns, and each maps onto memory retrieval:

Two rules sit on top of whichever pattern you choose. Keep a revoked-grant set and filter on it, which costs almost nothing and makes revocation effective within one query even before the purge job runs. And fail closed: if the permission check errors or returns an empty list, return no memories from that source, and never run retrieval unfiltered. The WorkOS post says it directly, that code which skips the filter when the list is empty "turns 'no access' into 'full access.'"

Some sources never tell you a permission changed. AWS's 7 October 2026 post on access control for RAG notes that synced ACLs are "a snapshot in time from when the last sync ran" and that Confluence does not emit an event when group membership changes. AWS's answer for Amazon Quick and Bedrock Knowledge Bases is a live check against the source at query time, after which a revoked employee's access is reflected in AI responses "within moments, not hours or days." For memory built from sources like that, a read-time check against the source (or a frequent reconciliation sweep) is the only control that notices the change at all.

4. Purge derived memory when the revocation event fires

Wire the purge to the events that already exist: a SCIM active: false or delete, an identity provider deactivation, an OAuth grant revocation, a connector disconnect, a role removal and a source permission change where the source emits one. For silent sources, schedule a sweep that compares stored permissions against the source.

The purge itself searches by provenance, because a user ID finds only half of what needs to go. Find every memory whose via matches the revoked grant, connection or principal, along with every memory whose derived_from chain reaches one of them; delete the facts, their embeddings and any cached tool results; regenerate or delete the derived summaries; and write tombstones so that restoring last week's backup does not bring the purged memories back. Preview the count before it runs, because a provenance bug that matches too broadly is itself an incident. Backups that cannot be edited should age out on a retention period you can state.

Some records should survive the purge. Decision logs, audit trails and records a regulator or a dispute may need are archived separately from operational memory, a split Roval and UC Today both recommend, and they should not be readable by the agent at retrieval time.

5. Audit what was read, what was purged and what was kept

WorkOS calls the read log a "copy inventory": once the connection is cut, the only honest answer to "what does that agent still have?" is what your logs say it read, keyed to the connection and bounded by the revocation timestamp. Pair it with a purge record per revocation event: the trigger, the grants matched, memories found, deleted, regenerated and retained with a reason, and who approved any exception.

Then prove the purge worked. The NHI Management Group's line, "Ticket closure is not evidence of access removal," applies to memory as much as to credentials. After the purge, run retrieval as a user without the revoked permission, ask the questions the purged memories used to answer, and confirm nothing comes back. A seeded fact with a known answer makes this a repeatable test; our one-week agent memory test plan covers how to script multi-session histories with an answer key, and a revocation case fits into it as one more scripted history.

6. Shorten the window before anything goes wrong

Every revocation is bounded by how long the grant was alive. RFC 7009 notes that short-lived access tokens let the authorization server "impose a limit on the time revoked when access tokens are in use," and for an agent the same dial bounds how much gets copied before anyone reviews the grant. The Zeabur incident report shows the other end: a shared cluster admin token created on 10 January 2024 with no expiry, never rotated, and used by an attacker from 14 October 2026, after which 3,218,965 environment-variable records were read from Zeabur's platform database. WorkOS's 27 October lesson from it is to rotate by inventory, not by memory. Every long-lived grant your agents hold should be on a list with an owner, a reach and a rotation date, and the agent itself needs an accountable owner who outlasts the person who built it.

In what order should you offboard an agent with memory?

1. Revoke the token, grant or connection, so no new reads happen.
2. Add the grant, connection and principal to the revoked set, so read-time filtering hides their memories on the next query.
3. Stop background jobs and clear cached tool results tied to the grant.
4. Run the provenance purge with a preview, including embeddings and derived records.
5. Regenerate the summaries and consolidations that lost a parent.
6. Write tombstones and confirm when affected backups age out.
7. Verify by querying as a user without the permission.
8. Close the audit record: event, matched grants, counts, exceptions, approver.

For a full retirement, add the steps the credential guides already cover well: map downstream workflows and agree a fallback before shutdown, revoke outbound access before inbound, and archive what must be kept before deleting the rest.

What if the agent is someone else's?

When the agent runs in a vendor's product under your employee's account, none of the purge steps are yours to run. WorkOS's advice holds: keep grants short, hand out references instead of full records, log every read keyed to the connection, and put context reset into the offboarding runbook and into the contractor agreement and vendor data processing agreement, because it is enforced by agreement rather than by code.

What to ask a memory vendor about revocation

• When a connection or user is revoked, what happens to memories already written through it?
• Does each memory record the connection, grant or principal it was read through, and can I delete by it?
• Do summaries and consolidated memories keep links to every source they absorbed?
• Can retrieval filter by source permission at read time, and does it fail closed?
• Does an erasure or purge reach embeddings, caches and derived records, and can I preview it?
• How long do purged memories survive in backups, and can a restore bring them back?
• Is there an audit record of reads and purges I can export?

Where Maximem Synap fits

Maximem Synap is a memory layer, so the checklist above applies to it the same way it applies to anything you build, and the vendor questions are fair to ask us. Scope is assigned at write time across client, customer, user and conversation, with nested hierarchies to any depth, and a read sees its own level and those above it, never below and never sideways, so one person's memory does not reach another person's session and one tenant's memory does not reach another tenant's. Every memory carries provenance: where it came from, what it replaced, why it changed and what it used to say. Erasure is per person and previewed before it runs. What an individual API key can see is configurable, with reveal set to full, masked or none, and payment card details, security codes, PINs, passwords, API keys, private keys and raw biometric data are never stored, with no setting that turns that off. Organisation context from Google Drive, Notion, SharePoint, Slack, Linear, Mintlify and Zendesk is held at a different level from user memory and kept apart from it. For how memory differs from a permission-filtered document index in the first place, see our agent memory versus RAG comparison.

Frequently asked questions

Does revoking an OAuth token delete an AI agent's memory?

No. Under RFC 7009 a revoked token and its grant cannot be used again, but nothing the token already fetched is touched. Facts, embeddings, summaries and cached tool results written before revocation stay readable until a separate purge removes them, and only a read-time permission check hides them in the meantime.

What should an AI agent offboarding checklist include for memory?

Identify which event you are handling (agent retired, user offboarded or one source revoked), then revoke the grant, filter its memories at read time, purge by provenance including embeddings and derived summaries, handle backups, verify by querying without the permission, and record what was read, purged and kept. Credential steps (inventory, rotation, short-lived grants) sit alongside, not instead.

How do you remove one user's data from shared agent memory?

Delete by the credential, not only by the user. Memories about the user are found by user ID; memories learned through the user's credentials are found only if each memory recorded the connection or grant it came through. Derived summaries that used those memories must be regenerated or deleted, or they keep answering other users' questions.

Do I need to delete embeddings when I revoke access?

Yes, if they were built from data read through the revoked grant. Research by Morris and co-authors recovered 92% of 32-token inputs exactly from their embeddings, so an embedding is a copy of the source in another encoding.

How fast should revocation reach an agent's answers?

On the next query, if retrieval filters on a revoked-grant set or checks the source at read time. AWS reports that its live check for Amazon Quick reflects a revoked employee's access "within moments, not hours or days." A purge that runs on a schedule is cleanup; it is not what makes revocation effective.

Sources

Every page below was read on 28 October 2026.

• AI agent deprovisioning, Maria Paktiti, WorkOS, 19 October 2026
• RAG access control: 3 ways to enforce document permissions in AI apps, WorkOS, 12 October 2026
• The token that never expired: What the Zeabur breach teaches SaaS teams that store customer secrets, WorkOS, 27 October 2026
• Zeabur October 2026 security incident (preliminary report), Zeabur, 19 October 2026
• Hindsight Cloud October 2026 update, Hindsight, 27 October 2026
• RFC 7009: OAuth 2.0 Token Revocation, IETF, August 2013
• Designing lifecycle policies for AgentCore memory, AWS Machine Learning Blog, 4 September 2026
• Rethinking access control for RAG with Amazon Quick and Amazon Bedrock, AWS Machine Learning Blog, 7 October 2026
• Text Embeddings Reveal (Almost) As Much As Text, Morris, Kuleshov, Shmatikov and Rush, arXiv 2310.06816
• Agent decommissioning: how to securely offboard AI agents, Roval, 16 April 2026
• AI agent leaver workflows expose the NHI offboarding gap, NHI Management Group
• Decommissioning AI agents: what to look for, Kovrr
• AI Agent Offboarding, UC Today