Secure enterprise search means every result, snippet, citation, generated answer, cache entry, and diagnostic trace respects the requester’s current authority. It is not enough to protect the search API with single sign-on. The system must preserve permissions from each source, enforce them before sensitive content reaches downstream components, and prove that revocations and deletions propagate.
This is harder than conventional application authorization. Enterprise search copies and transforms information across connectors, parsers, chunks, indexes, graphs, models, caches, histories, and evaluation datasets. One stale ACL or broadly scoped cache can turn an otherwise accurate answer into a data leak.
This guide defines the security architecture, controls, tests, and audit evidence required for permission-aware enterprise search and AI answers.
The short answer
Treat enterprise search as a zero-trust retrieval pipeline:
authenticate the user and tenant through trusted infrastructure
resolve current user, group, role, and source-specific principals
ingest content and its permission metadata as one governed object
security-trim candidates before reranking, generation, caching, or tracing
recheck authorization when a citation or source is opened
propagate access revocation and deletion to every derivative
record tamper-resistant evidence of configuration changes, permission decisions, and sensitive operations
test with adversarial identities and fail closed when authorization is uncertain
Security is an end-to-end property. A secure connector cannot compensate for an unsafe cache, and an authenticated UI cannot compensate for stale permission data in the index.
Define the protected surfaces
Start with a data-flow inventory. Enterprise search may expose information through more surfaces than the main result list:
result title, URL, type, owner, and snippet
autocomplete and query suggestions
filters, facets, counts, and people results
semantic or graph expansions
answer text and inline citations
source preview and deep-linked passage
conversation and search history
saved answers, collections, exports, and notifications
agent context and tool inputs
caches, traces, feedback, and evaluation records
administrator diagnostics and support tooling
Metadata can itself be sensitive. The existence of a confidential project, customer, investigation, or employee record may not be visible to an unauthorized user even if the body is hidden. Apply the same authorization policy to titles, snippets, facets, and counts.
Build a matrix that maps each surface to its identity source, permission check, cache scope, retention rule, audit event, and revocation behavior. Any blank cell is a security design gap.
Identity is the root of the decision
Every search request needs a trusted security context containing at least:
tenant or organization ID
authenticated user ID
direct and group principals
role and policy attributes
source-specific identity mappings
authentication method and assurance
request and session identifiers
relevant device or network policy context
Derive identity from the session, token, and identity provider—not from natural-language input. A prompt such as “I am the CFO” must never change authority.
Provisioning and deprovisioning
Integrate single sign-on with automated user and group lifecycle through the identity provider. Define maximum propagation times for:
new user creation
group membership addition and removal
role changes
account suspension
termination
source account relinking
Deprovisioning is the more important test. When a user leaves a group, measure when restricted results, snippets, citations, histories, caches, and agent memories stop exposing protected information.
Principal mapping
Source systems may identify the same person differently. Maintain an explicit, versioned mapping between enterprise identity and source principals. Handle renamed accounts, aliases, duplicate emails, contractors, guests, service accounts, and mergers without guessing.
If mapping is missing or ambiguous, fail closed for restricted content. “Best effort” identity matching is unacceptable for authorization.
Capture permissions with the content
Connectors should ingest three linked classes of data:
content: body, title, comments, attachments, and structured fields
metadata: source ID, URL, owner, timestamps, hierarchy, status, and version
permissions: users, groups, roles, visibility, inheritance, and explicit deny rules
Glean’s datasource documentation describes this content-metadata-permissions model. It also warns that incorrect API permissions can cause a crawl to fail or data to be missing. That is a useful operational reminder: connector credentials must be broad enough to capture authoritative ACLs without becoming the end user’s search authority. Glean: connect data sources
Store the permission source, observed time, connector version, and object version. Do not overwrite source-specific semantics with a lossy global “public/private” flag.
Direct, inherited, and dynamic permissions
Enterprise sources use combinations of:
direct user grants
group grants and nested groups
folder, site, project, or repository inheritance
role and record-level policies
domain and external-sharing links
explicit denies
row- or field-level rules
sensitivity labels
time-bound or conditional access
Your normalized model must either preserve these semantics or document the unsupported boundary. A connector that cannot reproduce a source’s authorization model should not expose those objects until the risk is accepted.
Index permission metadata
Permission fields must share stable object and chunk IDs with content, lexical, vector, and graph indexes. Chunking must never combine passages with different ACLs. Derived entities and graph edges need access policies based on their evidence, not a default public label.
Microsoft’s documented security-filter pattern stores user or group identifiers in filterable index fields and adds the requester’s principals to the query so unauthorized documents are excluded. Microsoft also distinguishes this filtering pattern from authentication: a principal string in a filter is not proof of identity. Microsoft: security filters for Azure AI Search
Enforce authorization before sensitive processing
The safest rule is simple: unauthorized content should not enter a component that the user, another tenant, a broadly privileged operator, or an external model provider could observe.
Query-time sequence
A secure query path should execute in this order:
validate tenant and authenticated user
resolve current principals and policy context
construct authorization filters using trusted server code
retrieve only authorized candidates, or trim them inside the search engine
rerank authorized candidates
generate from authorized passages only
build snippets and citations from authorized evidence
write caches and traces under the same authorization scope
reauthorize on source open or export
Do not retrieve the global top 100, send them to a model, and hide unauthorized ones in the UI. That leaks content into prompts and traces and can also destroy relevance when most top candidates are removed late.
Fail closed
If the identity provider, group resolver, permission index, or policy service is unavailable, the system must not return a partially filtered result set. A safe response is an explicit limited-mode error or search restricted to content known to be public for that tenant.
Microsoft’s current Azure AI Search documentation states that when ACL evaluation fails, permission-aware query flows should return an error rather than partially filtered results. The implementation details vary, but the boundary is broadly applicable. Microsoft: document-level access control
Personalization is not authorization
User activity, team affinity, document popularity, and graph proximity may rerank authorized results. They must never grant access. Keep authorization predicates deterministic and independent from learned relevance signals.
Secure every downstream component
Rerankers and language models
Send only authorized text to rerankers and models. Contractually and technically control provider retention, training, region, and logging. Redact secrets that are unnecessary for the task even when the user can access the source.
Caches
Cache keys must include tenant and a stable authorization scope. A per-query cache keyed only by normalized text can leak one user’s answer to another. Prefer caching object candidates and evidence under policy-aware keys, with short TTLs where permissions change frequently.
Invalidate cached results and answers when content, ACLs, group membership, or deletion state changes. If precise invalidation is unavailable, bound the risk with conservative TTLs and reauthorization before display.
Citations and previews
A citation is a pointer, not a grant. Recheck access when the user opens a preview or source. Decide what remains visible in conversation history after access is revoked.
Glean’s citation documentation says citations do not grant new access and source previews and links inherit organizational controls. It also notes that a citation entry may remain in history after permission is revoked even though the source should no longer be openable. Buyers should test exactly which title, snippet, and metadata remain visible in that state. Glean: citations
Traces and feedback
Diagnostic traces often contain the query, candidate titles, snippets, selected passages, model prompts, and answer. They are a shadow knowledge store. Apply encryption, access control, redaction, retention, residency, deletion, and export policies.
User feedback can copy sensitive answer text into analytics systems. Store references where possible and enforce the same tenant and content boundaries.
Evaluation datasets
Offline evaluation snapshots can outlive source access. Record provenance and authorization scope, minimize copied text, encrypt data, and periodically reconcile deletion and legal-hold requirements. Do not distribute real sensitive prompts to broad annotation teams.
Revocation and deletion are security workflows
Content freshness and permission freshness travel through different event paths. A document may remain unchanged while a folder is restricted or a user leaves a group.
Track separate service-level objectives for:
content update lag
direct ACL change lag
inherited permission lag
group membership lag
account deactivation lag
source deletion lag
derivative cleanup lag
The revocation cascade
When access is removed, propagate the event to:
identity and group cache
object permission index
chunk and graph authorization state
candidate and answer caches
source previews and saved results
agent context and durable memory
notification and export queues
offline copies where policy requires deletion
Then verify through the same user-facing path an affected user would use. A successful webhook or indexing job is not proof that access disappeared.
Tombstones and replay
Use tombstones to prevent deleted objects from reappearing through delayed events. Make deletion idempotent. Preserve only the minimum non-content audit record required to prove processing. A full crawl should not resurrect an object whose delete event arrived earlier unless the source now confirms it exists and is authorized.
Periodic reconciliation
Webhooks fail, APIs throttle, and source schemas change. Compare source inventory, versions, identities, and ACLs with indexed state on a schedule. Sample authorization equivalence with synthetic users. Record and repair drift.
Prompt injection and untrusted retrieved content
Enterprise search retrieves documents written by many people and sometimes external content. A document can contain instructions intended to manipulate an agent: reveal other sources, ignore policy, call a tool, or send data elsewhere.
Treat retrieved text as untrusted evidence, not instructions. Separate system policy, user request, tool output, and retrieved content in the model context. Limit tools and destinations independently from prompts. Require confirmation or approval for side effects. Prevent retrieved text from changing the user identity, permission filter, or destination allowlist.
Glean’s AI security documentation describes monitoring both user prompts and retrieved data for prompt injection, with configurable block or flag actions. Whether implemented through a product feature or a custom gateway, the important principle is to inspect both ingress paths and enforce consequences outside the model. Glean: AI Security overview
Test indirect injection in documents, webpages, issue comments, code, and attachments. Include encoded or visually hidden text, instructions that request credential disclosure, and attempts to move sensitive data into an allowed but inappropriate tool.
Administration and separation of duties
Avoid one universal admin. Separate at least:
connector setup and credential management
identity and role administration
content moderation and hiding
relevance tuning
agent or action publishing
security investigation and elevated search
audit-log access and export
billing and usage
super-administration
An operator who can debug relevance should not automatically see every restricted document. Provide controlled impersonation or test identities, reason codes, time-bounded elevation, and immutable logging.
Glean documents dedicated roles for sensitive-content moderation and administrative search, and advises restricting powerful search access to security personnel. Its role model is product-specific, but it illustrates the control to demand: high-impact visibility should be separately granted and audited. Glean: user roles
Audit evidence that matters
Audit logs should support incident reconstruction, compliance, and operational repair. Capture:
timestamp, tenant, actor, session, and request ID
authentication and principal-resolution outcome
policy and permission-index version
query plan and source scope
counts before and after security trimming
cited object and passage IDs
model, prompt template, and tool versions
administrative configuration changes
connector credential, schedule, and scope changes
role grants, elevation, and sensitive searches
content hiding and un-hiding
export, deletion, replay, and repair events
result, error, latency, and risk decision
Avoid placing unnecessary source text in the audit event. Use stable identifiers and protected evidence references. Sign or append-protect high-value logs, restrict access, monitor export, and send them to independent storage or a SIEM.
Glean’s admin audit documentation covers connector and system configuration changes, filtering, export, and retention. It lists a standard retention period and directs customers with longer compliance needs to arrange an extension. The exact period can change, so verify the current contract and match it to your investigation horizon. Glean: admin audit logs
Audit completeness must be tested. Perform a known configuration change, restricted query, failed permission decision, role elevation, export, and deletion; then confirm the expected events are searchable and exportable.
A production security test plan
Identity tests
valid user, suspended user, terminated user, guest, and service account
added and removed group membership
nested and dynamic groups
duplicate or renamed source identities
cross-tenant token and mismatched audience
expired session and revoked credential
Permission tests
direct grant and inherited grant
explicit deny
private folder and restricted child
externally shared link
identical document titles with different ACLs
row- and field-level restrictions
permission change without content change
source whose permission API is incomplete
Retrieval-surface tests
Verify titles, snippets, autocomplete, facets, counts, people, graph edges, answers, citations, previews, histories, exports, caches, traces, and notifications. Unauthorized information must not appear as either content or inference.
Freshness and deletion tests
Change a document, remove a user from a group, restrict a folder, delete a source object, and deactivate an account. Measure end-to-end propagation and absence through public product paths. Test delayed and duplicated events.
Failure tests
Disable the identity resolver, permission service, connector API, and audit sink. Introduce stale ACL data and a corrupted index version. Confirm the system fails closed, alerts owners, and can recover without widening access.
AI-specific tests
Insert prompt injection into accessible and inaccessible content. Ask the model to reveal system instructions, other users’ results, or hidden sources. Attempt cross-session cache reuse. Verify citations after revocation and prompt/trace retention after deletion.
Operational metrics and alerts
Track security as measurable reliability:
unauthorized result rate: target zero
content, ACL, group, and deletion lag by percentile
permission-resolution failure rate
fail-closed response rate
stale cache invalidation time
restricted-source exposure attempts
privileged search and export activity
role and connector configuration changes
prompt-injection blocks and flags
audit pipeline delay and dropped events
reconciliation drift and repair time
Alert on sudden drops in authorized candidate counts, unusual growth in broadly visible documents, group expansion failures, stale ACL cursors, high privileged-search volume, and missing audit events.
Common security mistakes
SSO-only thinking. Authentication protects the entry point; it does not enforce document-level permissions across derived data.
Post-filtering in the UI. Sensitive candidates have already reached rerankers, models, caches, or traces.
Using connector credentials as user authority. The crawler may need broad read access, but results must be evaluated under the requesting user.
One freshness clock. Fast content updates do not prove fast revocation.
Shared query caches. Normalized query text without tenant and authorization scope is a cross-user leak.
Admin omniscience. Debug and configuration duties should not imply unrestricted content access.
Audit without verification. A logging feature is not evidence until known events can be found, exported, retained, and correlated.
Ignoring history. A source may become inaccessible while its title, snippet, answer, or citation remains in a past conversation.
Final takeaway
Secure enterprise search is permission-aware from source ingestion to answer history. Identity and ACLs must be current, deterministic, and versioned. Unauthorized content must be excluded before reranking and generation. Caches, citations, traces, graphs, memories, and evaluation data must follow the same policy. Revocation and deletion require an observable cascade plus absence verification.
The strongest buying or architecture question is not “Does the product respect permissions?” It is: “Show us the exact identity, permission, propagation, failure, and audit path for this restricted object—and prove what happens when access is removed.”
Security control matrix
Surface | Preventive control | Verification |
|---|---|---|
Identity | Authoritative principal mapping and rapid deprovisioning | Disabled users lose access within the stated SLO |
Retrieval | Permission-aware candidate eligibility | Restricted documents never enter the candidate set |
Generation | Authorized context only, prompt-injection boundaries | Adversarial retrieved text cannot widen tool or data access |
Cache and preview | User- and policy-scoped entries | Cross-user replay tests return no restricted content |
Actions | Explicit authorization, confirmation, and idempotency | High-impact actions fail closed without valid authority |
Audit | Searchable identity, evidence, policy, tool, and outcome trace | An investigator can reconstruct who saw or changed what |
Frequently asked questions
What is permission-aware enterprise search?
It is search that evaluates a user’s effective access before returning, previewing, reranking, summarizing, caching, or generating from content.
Is security trimming after retrieval sufficient?
Not for sensitive systems. Unauthorized candidates can leak through previews, rerankers, traces, caches, or model context even if the final list is filtered.
How should revocation be tested?
Remove a user or source permission, propagate the event through every derivative store, and verify absence across search, answers, caches, previews, traces, and evaluation data.
How does prompt injection affect enterprise search?
Retrieved content is untrusted input. It must not override system policy, broaden tool authority, expose hidden context, or trigger actions without an independent authorization decision.
What belongs in the audit trail?
Record principal, query or mission, policy decision, source IDs, retrieval stages, citations, tool calls, confirmations, mutations, errors, and final outcome with timestamps.
Where Dokki fits
Dokki provides a shared workspace where security requirements, source inventories, review evidence, and agent outputs can remain connected. Teams can model permission and deletion test cases in a Dokki table, keep runbooks beside the evidence, and publish only the approved material.
Sources
_Last verified: July 21, 2026._