TECHNIQUE
Guardrails & Safety
Access-control-aware retrieval is implemented as user-scoped retrieval/authorization outside the LLM: deployed operators bind results to ACLs, OAuth scopes, or user-owned memory, while an announced Meta design adds agentic access decisions with rule-based guardrails.
Apply per-user permission checks to retrieved content before it is shown or supplied to the LLM: Dropbox says retrieved results are “personalized and ACL’d to you,” Slack uses the requesting user’s ACL so the LLM only receives data the user can already access, and LinkedIn limits semantic memory indexing to an individual user’s accessible memory.
3 of 5 deployed operators in the pool have direct evidence of per-user ACL or user-scope filtering.Use scoped OAuth-style authorization for external application retrieval or tool calls: Slack authorizes Slack to read only files the user can access and requests only necessary read scopes; Arcade.dev requests minimum necessary permissions and keeps token management on a trusted server.
2 of 5 deployed operators in the pool have direct evidence of scoped OAuth or minimum-scope external access.Fetch permissioned external results at query time when freshness and source-side permissions matter: Slack uses partner public search APIs to return up-to-date, permissioned results for the given user and says fetching external sources in response to a query avoids stale data.
1 of 5 deployed operators in the pool has direct evidence of federated, query-time permissioned external retrieval.Pre-index content or memory, then enforce user scope during retrieval/ranking: Dropbox stores embeddings, chunks, and graph representations, uses BM25 plus dense vectors, and applies ACL-aware ranking; LinkedIn persists conversation embeddings in a vector store and limits semantic memory indexing to the individual user’s accessible memory.
2 of 5 deployed operators in the pool have direct evidence of indexed retrieval with user-scope or ACL-aware use.Keep sensitive data out of unnecessary LLM exposure: Slack uses RAG instead of training LLMs and supplies only the content needed for the task; Arcade.dev frames its auth flow as handling credentials and API keys without exposing sensitive data to the LLM.
2 of 5 deployed operators in the pool explicitly describe limiting sensitive data exposure to the model.Announced pattern: use agents to assist warehouse access decisions, then check LLM decisions against rule-based risk calculations and store decisions/logs for analysis.
0 of 5 deployed operators are counted for this practice; 1 announced operator reports it.Where the pool has direct evidence of access-control-aware retrieval, operators bind retrieval or authorization to a specific user context rather than a generic corpus: Dropbox says results are ACL’d “to you,” Slack uses the requesting user’s ACL, LinkedIn limits scope to the individual user’s accessible memory, and Arcade.dev checks tokens by user and enforces scopes on a trusted server.
The common implementation boundary is outside the generative model: operators use retrieval ranking, ACL checks, OAuth/token handling, or scoped memory before content or credentials reach the LLM.
Operators differ on where permission enforcement sits in the retrieval path.
APPROACH 01
ACL-aware internal search/ranking over indexed work content.
APPROACH 02
Federated partner search/OAuth retrieval that returns permissioned external results for the requesting user.
APPROACH 03
Tool-call authorization pattern: the trusted server manages tokens and enforces scopes so MCP clients do not handle credentials.
APPROACH 04
User-scoped memory retrieval rather than enterprise document ACL retrieval.
Operators differ on freshness strategy for permissioned content.
APPROACH 01
Query-time external fetching to avoid stale external data.
APPROACH 02
Pre-indexed or periodically synchronized stores, with retrieval/ranking over stored representations.
Operators differ on whether the access-control logic is deterministic authorization or agent-assisted decisioning.
APPROACH 01
Deterministic user ACLs, OAuth scopes, or user-owned memory scope bound retrieval before model use.
APPROACH 02
Announced agent-assisted warehouse access decisions with rule-based risk guardrails and human oversight.
Sensitive-data leakage remains the core risk operators design around: Dropbox says granular access controls prevent sensitive company information from being surfaced unintentionally, Slack keeps customer data inside its trust boundary and limits LLM input by ACL, and Arcade.dev avoids exposing sensitive data to the LLM during credential/API-key flows.
External-app retrieval depends on scoped credentials and secure auth plumbing: Arcade.dev reports MCP lacks a secure third-party credential mechanism and calls current workarounds security anti-patterns; Slack explicitly limits OAuth scopes to those necessary for search queries.
Freshness is an explicit design pressure for permissioned external content: Slack says query-time fetching avoids stale external data, while Dropbox reports periodic syncs and webhooks for connected systems.
Agentic access decisions introduce malfunction/attack risk that Meta says it mitigates with rule-based risk control, output guardrails, and current human-in-the-loop oversight; this is announced evidence and not counted as deployed prevalence.
| 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 |