Enterprise Search: Can Revoked Permissions Be Reflected Within Minutes?
Minutes-level revocation depends on every access path: distinguish agent and API-key access from source permissions, then test propagation before promising a deadline.
Minutes-level revocation is possible only when every relevant access path meets that target. Removing agent access is different from changing a document’s permissions in a source system. This guide separates the controls and explains how to test propagation; it does not establish an end-to-end revocation SLA.
Key takeaways
How revocation reaches search results
- Platform access: Seahorse documents immediate agent-session termination and API-key rejection for specific controls. These do not establish an end-to-end source-permission SLA.
- Empty user-list exception: With authentication required, an empty selected-user list permits all authenticated tenant users; it does not deny everyone.
- Content removal: Deleting a Storage file removes its content for everyone using it; it is not a substitute for revoking one person’s access.
- Source permissions: Detection, indexing, identity updates and caches can all add delay. Filters depend on the permission data they use.
Case 1: Revoking access in the platform
Seahorse Cloud lets teams restrict an agent to selected users and connect it to selected Storage-created tables. Its manual documents immediate termination of a removed user’s ongoing session. However, with Require Authentication on, an EMPTY selected-user list permits ALL authenticated tenant users. Removing the final selected user must not be treated as deny-all; ensure the resulting configuration remains restricted. See the agent update manual.
Programmatic access is separate. The API-key deletion manual states that calls using a deleted key immediately receive an authentication failure (401). This revokes that credential; it does not establish per-document authorization for other users or keys. Revocation also cannot recall text already delivered to a user. See API-key deletion.
Case 2: Revoking access in a source system
When a document’s permissions change in SharePoint, a file server or another source, the search index does not know until something tells it. Platforms handle this in two ways.
Indexed permission metadata. In supported configurations, Azure AI Search can ingest document permissions and enforce them at query time. Source and ingestion support determine how those permissions are refreshed. Total delay can include source-change detection, index processing, group or token updates and caches—not just the sync interval. Azure document-level access documentation.
Query-time filtering. Azure security filters compare supplied identity values with indexed permission fields; they do not inherently make a live authorization call to SharePoint. Elasticsearch document-level security limits which documents a role can read. Both depend on the freshness of the identity and permission data used. Azure security filters; Elasticsearch document-level security.
Designing for per-document permissions in Seahorse Cloud
Seahorse Cloud provides agent and API-key access controls. The cited manuals do not establish automatic inheritance of every external document ACL. Keep audience segmentation distinct from content removal:
- Audience segmentation. Place documents with a shared audience in a dedicated Storage, connect its table to an agent and configure permitted users. Ensure other agents, keys and tools do not offer an unintended route to the same content, and check the empty-user-list exception above. Agent Users and Tables settings.
- Content removal for everyone. Deleting a Storage file removes the file and its vector chunks and cannot be undone. Use this when the content should no longer be available from that Storage to anyone; it is not a substitute for revoking one person’s access. Storage file deletion.
When each user’s rights must mirror source permissions document by document, enforce authorization in a trusted application or retrieval layer BEFORE restricted passages enter the model’s context. Cover direct API, tool and alternative-agent routes as well as the chat interface.
A compact revocation test
- Select a test document, the affected user and a control user who should retain access. Record the permission-change time.
- Test existing and new sessions plus relevant API and tool routes, including the empty-user-list case. Restricted passages, snippets and citations must not reach the model or the affected user.
- Record the first confirmed denial on each route and verify that the control user retains legitimate access. Repeat under representative update and cache conditions.
- Use these results to set an operational target and monitoring plan. They measure propagation in the tested configuration, not a universal revocation guarantee.
FAQ
Can revoked access take effect immediately?
Seahorse’s manuals describe immediate termination of a removed agent user’s session and 401 responses for deleted API keys. Check the resulting agent configuration: an empty selected-user list with authentication required permits all authenticated tenant users. Source permission changes depend on their propagation path.
Does automatic vector sync update permissions?
Keeping Storage content and vector chunks synchronized is different from importing external ACL changes. Confirm which permission metadata your integration updates and where it is enforced.
How should we test revocation?
Compare the affected user with a control user who should retain access. Record the change and first confirmed denial on each relevant session, API and tool route; include cache behavior and the empty-user-list exception. Measure results under representative conditions.
Review agent access settings
Map the intended audience to the agent’s Users and Tables settings, then test access with representative users.
