TECHNIQUE
Guardrails & Safety
Access-control-aware retrieval is deployed as user-scoped or source-scoped retrieval: operators fetch, rank, or expose only content allowed by ACLs, OAuth scopes, approved knowledge boundaries, or individual-user memory scope.
Bind retrieval results to the requesting user’s permission boundary: Slack uses the requester’s ACLs and says Slack AI only operates on data the user can already see; Dropbox applies ranking passes so retrieved results are “personalized and ACL’d”; LinkedIn limits semantic memory indexing to an individual user’s accessible memory; Florida Prepaid keeps the voice agent within public knowledge; Arcade.dev requests minimum necessary permissions for tool/API access.
5 of 6 deployed operators in the pool show an explicit user-, source-, or scope-bound access-control pattern; announced Meta evidence is not counted.Use source systems or existing search permissions as the enforcement point for enterprise search. Slack uses public search APIs from partners to return up-to-date, permissioned results and says search will never surface results standard search would not; Dropbox connects to third-party apps and then stores/indexes content for Dash with access-controlled retrieval.
2 of 6 deployed operators explicitly describe enterprise search over third-party or cross-app content with permission-aware retrieval.Pass only permissioned or approved context into the LLM/RAG step. Slack uses RAG so the LLM receives only needed content and enforces requester ACLs; Dropbox launched Dash with in-depth content access control and uses RAG for responses; Florida Prepaid’s agent answers from approved Salesforce Knowledge Articles and works only within public knowledge.
3 of 6 deployed operators explicitly tie generated answers to permissioned, access-controlled, approved, or public-only retrieved context.Use OAuth scopes or browser-mediated authorization for external tool retrieval instead of exposing credentials to the model or client. Arcade.dev implements URL elicitation for OAuth-sensitive flows and minimum necessary permissions; Slack uses OAuth for external systems and requests only necessary read scopes for search queries.
2 of 6 deployed operators explicitly describe OAuth/scope controls for external-system retrieval or tool access.Keep generated outputs aligned with access-control changes or deletion controls. Slack invalidates summaries derived from tombstoned DLP messages; Slack also says only the invoking user can see AI-generated output.
1 of 6 deployed operators explicitly describes invalidating derived AI outputs after access/deletion events.Across the deployed operators with explicit access-control-aware retrieval evidence, the model or agent is not treated as an authority to decide access by itself; access is bounded before or during retrieval by ACLs, OAuth scopes, approved/public knowledge, or individual-user memory scope.
Operators enforce the access boundary at different layers of the retrieval path.
APPROACH 01
Fetch-time ACL or source-permission enforcement: retrieve only what the requester can already access, including Slack ACL-based retrieval and partner APIs returning permissioned results; LinkedIn scopes memory retrieval to the individual user’s accessible memory.
APPROACH 02
Ranking-time access control: retrieve/index cross-app content and then apply ranking passes that are personalized and ACL’d to the user.
APPROACH 03
Source-bound answering: restrict the agent to approved or public knowledge rather than allowing account, case-history, balance, or personal-data retrieval.
APPROACH 04
Tool/API authorization boundary: use OAuth URL flows and minimum necessary scopes so external API retrieval is authorized without exposing credentials to the LLM or client.
Operators differ on whether retrieval is indexed ahead of time or fetched live from permissioned systems.
APPROACH 01
Indexed retrieval: Dropbox uses lexical BM25 plus dense vectors and access-controlled ranking; LinkedIn persists conversation embeddings in a vector store for semantic memory retrieval; Uber indexes internal documents into vector stores for RAG, though the pool does not show explicit ACL enforcement for Uber.
APPROACH 02
Live/federated permissioned retrieval: Slack fetches external data in response to a user query using partner search APIs and OAuth read scopes, avoiding stale external results.
APPROACH 03
Approved-knowledge retrieval for voice service: Florida Prepaid routes calls into Agentforce Voice and answers routine questions from approved Salesforce Knowledge Articles.
Unauthorized or over-broad exposure is the central risk operators design around: Slack says AI can only see the same data as the requester, Dropbox warns that granular access controls prevent sensitive company information from being surfaced unintentionally, Florida Prepaid excludes personal/account/case data, and Arcade.dev avoids exposing sensitive credentials to the LLM.
External-tool retrieval needs narrow credential scopes: Arcade.dev calls out service-account tokens with excessive scopes and token passing as production anti-patterns; Slack says it requests only the OAuth scopes necessary for search, specifically read scopes.
Access-control-aware outputs can become invalid when source content is removed or restricted; Slack explicitly invalidates summaries derived from DLP-tombstoned messages.
| Name | Kind | When | Maturity |
|---|---|---|---|
| ACL-filtered retrieval | pattern | permissions applied as query filters at retrieval time, not post-hoc | established |
| Postgres row-level security on pgvector | pattern | the vector store inherits the database tenancy model directly | established |