Enterprise AI Assistant Permissions After Revocation: A 16-Case RAG Test

Decision in brief. Enforce permissions at retrieval time, but do not stop there. A permission change can happen after an assistant has already retrieved a passage, placed it in conversation state, generated an answer, or cached a summary. For a multi-user assistant, the authorization question must include the requester, every intended answer recipient, the retrieved sources, the active conversation and any derived cache. Re-check that relationship at the boundary where content is used or disclosed. If access has been revoked and the application cannot establish whether prior context remains permitted, invalidate that context and require a fresh answer from currently authorized sources.

The search starting point here is the broad query assistant ia entreprise. For 27 October–3 November 2026, Google Search Console showed 89 impressions, zero clicks and average position 17.3 for the Vocalis page Assistant IA en entreprise. That small, short-window observation identifies a specific reader entry point; it does not establish market demand or predict ranking. Existing product and security guidance explains retrieval-time controls, least privilege and cache isolation. The missing operational question is what to do when permissions change during an open conversation or when the assistant is preparing an answer for several participants.

The permission decision has a time dimension

A classic document search asks whether a user can read a document now. An AI assistant may retrieve content at time T1, retain it in a conversation summary, and disclose a derived answer at T2 after a membership change. The original retrieval can have been authorized and the later disclosure still be inappropriate. The assistant’s internal context is not a new entitlement. A response cached for a previously authorized user is not automatically safe to reuse after the user, group, tenant, project, or conversation audience changes.

There are at least four distinct subjects to evaluate:

1. Requester: the authenticated person or service that submitted the current turn.
2. Agent identity: the application or agent principal used to fetch a record or invoke a tool.
3. Content principals: the identities or groups whose permissions apply to each source item.
4. Recipients: everyone who can see the answer, including conversation members, forwarded output, shared links or a downstream system.

For an answer intended for several people, access by the requester alone is not enough. An answer should only include a source if the disclosure policy allows that source to influence an output visible to every intended recipient. A conservative policy uses the intersection of recipients’ authorized sources. A different product may choose per-recipient rendering, but then it must prove that each recipient sees only their permitted version and that shared summaries, notifications and exports preserve that separation.

This is an engineering recommendation, not a universal legal rule. The institution’s actual data policy may permit some shared information while forbidding other classes. The central requirement is to make the policy explicit and enforce it outside model-generated prose.

What the evidence says

OWASP’s RAG Security Cheat Sheet describes access-control metadata at chunk level, retrieval-time enforcement, tenant isolation, cache scoping and invalidation when source permissions change. It warns against relying on a model to enforce access control and against serving cached responses after source permissions have changed. Those controls support the baseline of this article; the specific active-session test matrix below is an original operationalization, not an OWASP test suite. OWASP RAG Security Cheat Sheet.

NIST defines prompt injection as an attack exploiting the concatenation of untrusted input with a prompt constructed by a higher-trust party, such as the application designer. This matters to authorization because retrieved content may influence model behavior, while authority should remain in authenticated identity and policy services. The definition comes from NIST AI 100-2e2025; it is a definition, not a claim that every retrieved document is malicious. NIST prompt-injection glossary.

A 2025 research position paper, Enterprise AI Must Enforce Participant-Aware Access Control, argues that retrieval and fine-tuning must account for all users involved in an interaction. It presents attack scenarios where a user’s input can cause information to be surfaced to another participant, and argues that input sanitization and output filtering are probabilistic defenses rather than deterministic access controls. The paper is a research position with examples and a proposed framework, not proof that every commercial assistant leaks data or that one implementation pattern is sufficient. Bhatt et al., arXiv:2509.14608.

Microsoft’s Copilot data-protection architecture states that its product honors existing Microsoft 365 access controls for grounding and generation, and describes interactions with sensitivity labels, encryption, SharePoint and OneDrive controls. That is product-specific documentation; it should not be generalized to other connectors, configurations, products or custom assistants. The useful implementation question is whether your actual product’s authorization and revocation semantics cover the complete path from retrieval through conversation history and cache. Microsoft Learn: Copilot data protection architecture.

The Cloud Security Alliance’s application-provider guidance recommends least privilege, permission-change management and comprehensive access logging. This supports treating permission changes as a controlled, auditable lifecycle event rather than a directory update assumed to propagate everywhere immediately. It is governance guidance, not a latency guarantee for any connector. CSA AICM implementation guidelines.

For a broader governance frame, NIST describes the AI Risk Management Framework as a voluntary framework for incorporating trustworthiness considerations across the design, development, use and evaluation of AI systems. It does not prescribe this article’s session-invalidation sequence; that sequence is an engineering recommendation derived from the access-control problem. NIST AI Risk Management Framework.

Consulting sources can help frame operating-model questions but are not neutral product evaluations. EY’s AI services material presents AI strategy and implementation as organization-wide work; use it as a consulting-market perspective, not proof that a specific control works. EY AI services.

A practitioner discussion on Reddit raises a concrete unresolved question: if a person loses access to a project after the assistant already retrieved its records into conversation memory, how do later responses avoid exposing that information? Other comments call out cached responses, different error phrasing for protected versus absent records, and the need to log reads as well as writes. This is anecdotal discussion, not a measured prevalence estimate, but it surfaces the operational questions this test suite addresses. Discussion: “Permission leaks to check when putting an AI assistant on company data”.

A participant-aware answer policy

Define an answer context as a tuple containing the authenticated requester, intended recipients, conversation identifier, policy version, source set, content classifications and creation time. Each retrieved passage should carry a stable source identifier, access-control version or authoritative permission reference, tenant or workspace, classification, provenance and a digest. Keep source content out of diagnostic logs where possible; log enough to reconstruct which source identifier was evaluated, under which principal, with which decision.

For a turn with recipients R and candidate source d, a basic allow condition is:

• requester and each recipient are authenticated;
• the tenant and conversation match the request;
• current policy permits every recipient to receive information from d;
• d’s access decision has not expired or been superseded;
• d passed integrity and provenance checks;
• the response cache key is scoped to the same effective recipient set and policy version;
• any tool action has a separate authorization check.

If the application cannot evaluate recipients individually, reject multi-recipient requests for restricted sources or produce a response only for the requester in a private channel. Do not quietly broadcast a requester-only answer into a shared channel. If the policy service is unavailable, fail closed for restricted material unless a specifically approved, unexpired cache rule says otherwise.

A permission decision needs freshness semantics. “The index syncs every few minutes” is not a revocation guarantee. Specify a measurable maximum propagation objective, the policy source of truth, how active sessions are handled, and what happens when the objective is missed. For high-sensitivity sources, a synchronous authorization check at each use may be more appropriate than relying on asynchronous indexing. For lower-risk material, short-lived policy snapshots may be acceptable if an owner has approved the residual window and the cache is invalidated when changes arrive.

The response state machine

Treat permission change as a state transition with consequences, not just an event in a directory. The application should know whether a conversation is active, whether it contains restricted source-derived content, whether a permission event affects a requester or recipient, and whether a response is being prepared, cached or shared.

A useful implementation can distinguish source permission from derived-answer permission. If an answer contains only a public summary, it may be shareable under a broader policy. But that is a classification and disclosure decision, not something the model should infer from tone. If the system cannot reliably identify whether a generated statement depends on a restricted source, its safe option is to treat the answer as having the most restrictive classification among its inputs or regenerate from the recipient-approved source set.

Sixteen synthetic test cases

These fixtures are designed on 5 November 2026. They are synthetic and reproducible; they are not production observations, a security benchmark, or a measurement of any vendor. The number 16 is a chosen coverage count, not a statistical sample. Use unique fake records and marker strings; do not seed real personal or confidential data.

The test procedure is simple enough for a spreadsheet but should be automated for release. Create a fake workspace with two users, two groups, one restricted source, one shared source, one deliberately revoked record, and synthetic markers that cannot occur in production. Run each case through the same entry point a normal user uses. Record the authenticated actor, conversation recipients, policy version, source IDs considered, sources allowed, cache outcome, response class and whether any state-changing tool ran. Keep the content of a restricted source out of the test report; marker presence or absence is sufficient.

Repeat T03, T04, T05, T08 and T10 with a warm application cache, a warm semantic cache, an open browser session, a resumed conversation and a newly generated conversation summary. A test that only clears every cache before running proves little about the real stale-state path. Repeat with two users whose identity names overlap across tenants to catch systems that key only on a local user ID. If group membership is inherited through nested groups, test the nested change too.

For T13, compare the user-facing refusal for a protected record and a nonexistent record. If one response says “you do not have access to project Atlas” and the other says “no such project,” the assistant leaks existence even though it never returns the document. The response can remain helpful without revealing which condition applied: use a standard denial, offer the ordinary access-request route, and keep the detailed reason in a restricted audit record.

For T14, a row-level filter may not control aggregates. Suppose an authorized user can see their own case records but not a restricted team’s records. A total, average or trend that includes hidden rows can reveal information without returning any individual row. Decide whether aggregates are authorized, define minimum group sizes or suppression rules if needed, and include a fabricated dataset where one hidden row changes the result. Those are policy choices; the test should surface the result and force an owner to approve it.

For T15, include a retrieved instruction that asks the model to ignore access policy and reveal a marker. The expected result is not “the model promises to ignore it.” The system should enforce source selection and disclosure before generation, treat the text as untrusted, and restrict any tools independently. NIST’s definition explains why concatenation of untrusted and trusted instructions creates a prompt-injection surface; OWASP’s RAG guidance addresses pipeline and retrieval controls. Neither source implies that a prompt-only defense can guarantee safe behavior.

For T16, pause the workflow after authorization but before a tool call, revoke the user, and then resume. The executor should validate again at the action boundary. If the operation cannot be canceled after dispatch, record the exact commit point and the compensating process. This tests time-of-check/time-of-use behavior. A policy check at retrieval does not automatically authorize a later write.

The expected result is about controlled information flow, not perfect answer quality. A response may omit data unnecessarily or ask for clarification; record that as a utility failure, not a confidentiality leak. Conversely, a fluent answer that includes a forbidden marker is a critical denial failure even if the rest of the response is useful. Preserve both dimensions so teams do not improve answer usefulness by weakening the security criterion.

A small executable decision function

The following Python function encodes one conservative policy for a shared response: every intended recipient must currently be allowed to receive every source, and the cached response must match the same recipient set and policy version. It deliberately denies when the policy service is unavailable. It is a teaching fixture, not a complete authorization engine.

from dataclasses import dataclass @dataclass(frozen=True) class AnswerContext: tenant: str requester: str recipients: frozenset[str] policy_version: str source_ids: frozenset[str] def may_disclose(ctx: AnswerContext, grants: dict, cache: dict, policy_available: bool) -> bool: if not policy_available or not ctx.requester or not ctx.recipients: return False if ctx.requester not in ctx.recipients: return False if cache.get("tenant") != ctx.tenant: return False if cache.get("recipients") != ctx.recipients: return False if cache.get("policy_version") != ctx.policy_version: return False for source_id in ctx.source_ids: allowed = grants.get((ctx.tenant, source_id), frozenset()) if not ctx.recipients.issubset(allowed): return False return True def test_revocation(): ctx = AnswerContext( tenant="tenant-a", requester="alice", recipients=frozenset({"alice", "bob"}), policy_version="p8", source_ids=frozenset({"marker-project-x"}), ) grants = {("tenant-a", "marker-project-x"): frozenset({"alice"})} cache = { "tenant": "tenant-a", "recipients": frozenset({"alice", "bob"}), "policy_version": "p8", } assert not may_disclose(ctx, grants, cache, policy_available=True) grants[("tenant-a", "marker-project-x")] = frozenset({"alice", "bob"}) cache["policy_version"] = "p7" assert not may_disclose(ctx, grants, cache, policy_available=True) cache["policy_version"] = "p8" assert may_disclose(ctx, grants, cache, policy_available=True) assert not may_disclose(ctx, grants, cache, policy_available=False) if __name__ == "__main__": test_revocation() print("synthetic authorization assertions passed") 

This code uses a full recipient intersection because its stated policy is “all sources are shareable with all recipients.” A real product may instead provide separate private responses, redact fields per person, or permit a broader derived fact. Those approaches need their own data lineage and rendering proofs. The example also assumes the caller has already authenticated identities, resolved current groups, bound sources to a tenant, and supplied a trustworthy policy version. Never accept those values from model output or an untrusted client parameter.

The sample test covers one revoked recipient, a stale cache policy version, a fresh permitted state and policy-service failure. It does not test identity federation, nested groups, aggregate disclosures, semantic caches, race conditions or output transformation. The 16-case suite above identifies those additional fixtures. No claim is made that this short function alone secures an enterprise assistant.

Audit records that answer “what did the assistant see?”

Logging only writes is not enough to reconstruct an information disclosure. A response can reveal a restricted source without changing any business record. Record the decision path for reads and response releases: authenticated subject, effective recipients, tenant, conversation identifier, policy version, source identifiers evaluated, allow or deny results, cache status, authorization time, release decision and any downstream action identifier.

Minimize content in that trail. Logging full prompts, retrieved passages and generated answers may create a second sensitive repository with different permissions and retention. A source identifier plus a digest or a controlled reference can often prove which item was involved without copying its text. If an investigation later needs the content, use a separately authorized access path with its own audit event. Define who may correlate the event, how long the record is retained and how deletion or legal hold applies.

A correlation record should distinguish three outcomes: a source was never considered; it was considered and denied; or it was allowed into context. This distinction helps identify whether the failure occurred in candidate generation, authorization, cache reuse or final disclosure. Do not make the user-facing answer reveal the detailed denial reason when that would expose that a protected file exists. Store that detail in the restricted audit trail.

The audit event should also include enough timing information to evaluate revocation. Capture when the identity provider recorded the change, when the retrieval service learned about it, when the cache was invalidated, and when the next answer was generated. These timestamps let a reviewer compare the implementation with a stated propagation objective. A single “permission updated” flag cannot show whether an open session was invalidated before a later response.

Release sequence for a real assistant

A disciplined rollout separates plumbing checks from disclosure checks. Begin with synthetic records and a small set of test identities. Connect the source system, indexer, retrieval layer, conversation store, cache and output channel. Verify the identity passed from the application is derived from a trusted authentication context, not user-supplied text. Confirm that a tool call cannot substitute a broader service identity for the original user without recording and checking the delegation.

Next, seed the source corpus with marker records that represent different access scopes: public-to-team, private-to-user, restricted-to-project, and same identifier in two tenants. Put different random marker strings in each record. Ask permitted users for their own markers, then ask unauthorized users for the same markers in direct questions, paraphrases, requests for totals and questions about whether the marker exists. Ensure that the test does not expose real names or data.

Then test state transitions. Grant access, verify retrieval, warm the semantic and response caches, revoke access, and repeat through the existing conversation, a resumed conversation, a new conversation and a shared channel. Measure the time between the authoritative permission change and effective denial. Do not treat average latency as proof; retain the observed maximum for the tested fixtures and the conditions under which it was measured. If the product does not expose reliable invalidation, use a route that does not keep restricted context or narrow the feature to private, short-lived turns.

Finally, test the release boundary. If an answer is addressed to a group, evaluate every recipient. If the system posts into a channel, derive its audience from the channel’s current membership. If an answer is copied to a CRM, ticket or email, the receiving system has its own access policy and should perform an authorization check. A link to the original document does not undo a disclosure already embedded in the summary.

This sequence is a recommendation for repeatable verification, not a substitute for threat modeling or penetration testing. It avoids a common but weak acceptance pattern: test the vector search for one authorized user, see a correct answer, and conclude that enterprise permissions are safe.

Failure modes and recovery

Stale conversation summary. A summary may preserve restricted facts even after the source disappears from the latest retrieval. Mark derived context with source dependencies and policy version. On revocation, invalidate or rebuild that state. If dependency lineage is absent, start a clean context rather than assume the summary is harmless.

Semantic cache shared too broadly. Similar prompts can map to one cached answer despite different principals. Include tenant, recipient set and effective authorization scope in the key, or do not cache restricted responses. Invalidate entries when source policy changes. A time-to-live reduces exposure duration but does not replace immediate invalidation when policy requires it.

Permission sync lag. An asynchronous connector may keep an old group membership for a period. State the measured and accepted propagation objective, alert when it is exceeded, and select a safer path for data classes that cannot tolerate the window. Do not turn “sync runs frequently” into a guarantee.

Confused deputy. The retrieval service may have broad access and return material because the service account can read it, even though the person cannot. Enforce the end-user or delegated principal’s effective authorization at the retrieval boundary. Treat the application identity as a mechanism, not as evidence of the user’s entitlement.

Audience expansion. A private answer may later be pasted into a group chat, ticket or report. Recheck the audience at export or sharing time. If the system cannot evaluate the destination’s members, block restricted output or require a human to create an approved derivative.

Error side channel. Distinct refusal wording can reveal a record’s existence. Use a consistent user-facing denial where necessary, while preserving granular internal audit reasons for authorized reviewers.

Policy service outage. A stale cached policy is not automatically acceptable. Fail closed for restricted sources unless a specifically approved, unexpired snapshot and its revocation behavior have been tested. Make the user experience explicit: the assistant can retry or provide a manual route, but it should not silently broaden permissions.

Partial revocation during generation. A response may be generated while a group change occurs. Check again before releasing it. If the check fails, discard the candidate answer and regenerate from the current allowed source set. Do not simply remove citations while retaining restricted facts in prose.

Boundaries and counterarguments

Participant-aware filtering can reduce answer completeness. The intersection of all recipients’ access may omit useful material that the requester is authorized to see. That is a usability cost, not a reason to disclose it to everyone. A product can keep a private response for the requester, ask whether to share a redacted summary, or route the user to an approved access request. The interface should make that choice visible.

Not every conversation requires a group intersection. A private assistant turn may have one recipient. A service that never stores context may have a smaller stale-session surface. A fully public knowledge base does not need per-user source filtering, although it still needs integrity, safety and appropriate retention. Scale the test to the actual architecture and data classification.

There are legitimate product designs that use a privileged service account to retrieve broadly and then apply a secure policy layer. The security question is whether that layer is deterministic, independently enforceable and tested at every disclosure boundary. A claim that the model will omit restricted details is insufficient. Microsoft’s own documentation illustrates a product-specific implementation that honors the user’s existing rights during grounding; that statement does not prove equivalent semantics in a custom connector or a third-party conversation store.

A privacy-preserving audit can conflict with incident-response needs. Storing source IDs and decisions may be insufficient when investigators must confirm what exact text influenced a response. Define a controlled evidence-retrieval process, separate from routine logs, with authorization, purpose limitation, access expiry and documented retention. This lets the organization investigate without making every operator a reader of prompts.

Method, sample and exclusions

The original asset is a 16-case synthetic suite designed on 5 November 2026. It targets multi-participant answers, revocation during active sessions, stale summaries, warm caches, tenant overlap, delayed group propagation, policy-service failure, export, side-channel refusals, aggregate results, prompt injection and a race before downstream action. The code example includes four deterministic assertions. These fixtures were authored for this article; no commercial assistant was executed and no real user, tenant or company record was tested. The number 16 is a design coverage choice, not a prevalence or success statistic.

The GSC check used the AI-Due/Vocalis property data for 27 October–3 November 2026. The query “assistant ia entreprise” had 89 impressions, zero clicks and average position 17.3 on the page linked near the opening. This is a small, short-window observation and cannot establish market demand, user intent for every searcher or a future ranking outcome.

We read OWASP RAG security guidance, the NIST prompt-injection glossary entry, the arXiv participant-aware access-control paper, Microsoft Copilot architecture documentation, Cloud Security Alliance implementation guidance, the target site page and a practitioner discussion. The Reddit thread is anecdotal; comments are used to identify a question, not to estimate incident frequency. A search for a relevant conference talk found a video listing about fine-grained authorization in agentic AI, but the direct caption retrieval returned no transcript. It is therefore an access gap and is not used to support factual claims. The implementation details cited from Microsoft are product-specific; the paper is a research position; OWASP and CSA are guidance, not proof that a particular deployment passes the cases.

The target page itself includes numeric marketing claims about benefits, but the accessible excerpt did not supply a method, sample, period or exclusions for those numbers. This article does not repeat them as evidence. That omission is deliberate: a number without its measurement definition cannot answer whether an assistant is safe or useful for a specific workflow.

Acceptance checklist

Before enabling shared or persistent AI conversations, ask:

• Does every retrieved chunk carry a stable source identifier and current permission reference?
• Is authorization enforced before restricted text reaches the model?
• Is the requester identity derived from a trusted session?
• Are all intended recipients known at the time of release?
• Does a shared answer require authorization for every recipient or have a tested per-recipient rendering path?
• Does a permission change invalidate affected conversation context and all dependent caches?
• Are summaries and generated outputs linked to the sources that influenced them?
• Are warm-cache, resumed-session and group-membership changes tested?
• Are tenant IDs part of source, cache and conversation boundaries?
• Are aggregate answers tested for inference from restricted rows?
• Are refusal messages checked for record-existence side channels?
• Does the application fail closed when its policy service is unavailable?
• Are tool handlers authorized independently at execution time?
• Can a reviewer reconstruct reads, decisions, cache hits and releases without routine logs copying sensitive text?
• Are the policy version, propagation objective, owner and exceptions recorded?
• Are failures actionable, with a queue, clean-session retry or human route?

A team should not accept “the assistant uses the same permissions as the source system” as a complete result. Ask which principal is used, which path checks permissions, whether that check runs at retrieval and output, what invalidates active context, and how a shared answer is scoped. Then run the synthetic cases using the ordinary product interface and a traceable release build.

Recommendation

Start with a private, read-only assistant path, a small synthetic corpus and the 16 cases above. Block sharing if the audience cannot be resolved. Block restricted retrieval when current authorization cannot be verified. On revocation, discard stale context and re-evaluate rather than relying on the model to forget. Expand to shared responses only after the identity, recipient, cache, summary and export paths pass tests. That is a conservative release recommendation, not a universal product design or a claim that all enterprises need the same policy.

flowchart TD A[Authenticate requester and recipients] --> B[Resolve current policy version] B --> C[Filter sources before model context] C --> D[Generate candidate answer with source lineage] D --> E{Policy or recipient changed?} E -- Yes --> F[Invalidate context and cache; re-evaluate] E -- No --> G[Check every intended recipient] F --> B G --> H{All sources allowed for audience?} H -- No --> I[Block, redact safely, or keep response private] H -- Yes --> J[Release and log minimal decision trace]

The model may help phrase a refusal or summarize a permitted source; it should not decide whether a user is entitled to see that source. Let a trusted identity and policy layer authorize retrieval, let conversation state carry provenance, and make the release boundary re-check the audience. The most important test is not whether the assistant answers a normal question. It is whether the same system denies the previously authorized answer after a relevant permission change, including when a warm cache or open conversation tries to make yesterday’s access look current.