Knowledge assistants: set freshness and permission rules

Introduction

Knowledge assistants: set freshness and permission rules

Connecting a repository to an AI knowledge assistant creates a new way to distribute its contents. Before opening that connection, decide what users may receive when a document changes, somebody leaves a team, or a source becomes unavailable. A useful answer needs an identifiable source and an access decision that still applies.

Give each source a freshness budget

The practical starting point is a short agreement for each collection: its owner, permitted audience, update requirements, and behavior when those requirements cannot be met. This turns an open-ended integration into a decision the business and technical team can review together.

“Keep the knowledge current” leaves too much unresolved. A product handbook used for orientation and an operating instruction used during an incident can have different consequences when they are outdated. Ask the owner what a person might do with the answer, then define the maximum acceptable age of the evidence for that decision. Separate a document’s publication date from the time the system last verified its state; a recently indexed old policy remains old.

Connector schedules also face practical limits. Glean describes crawling as a balance between freshness and source API load, with different mechanisms for content, identity, and deletion. Treat the documented connector behavior as an input to your requirement. Measure whether the deployed integration meets that requirement before relying on its answers, and name the person who responds when synchronization falls behind.

Track content and permission changes separately

An unchanged document can acquire a different audience. An employee can move departments without anyone editing the files they previously used. A content update timestamp alone cannot describe whether access remains valid.

For each source, record two separate observations: when its content was successfully synchronized and when the relevant permissions were verified. Include identity or group changes where the authorization design depends on them. Define the acceptable delay for each, rather than borrowing the content refresh interval for permission changes.

Azure AI Search documents this distinction explicitly: native query-time authorization evaluates permission metadata already in the index, and source permission changes need the documented synchronization mechanism to reach it. Checking access during a query therefore does not automatically mean consulting the original source’s current permissions. Confirm which implementation your service uses. Microsoft marks native document access features as preview and does not recommend preview functionality for production workloads; include that constraint in the product decision.

Resolve identity before selecting the integration

A connector’s ability to read a library does not establish which employees may receive its contents. Write down how the application identifies the person asking, how that identity maps to source users and groups, and where the authorization decision is enforced.

Check contractors, renamed accounts, and users whose group membership recently changed. Choose the intended behavior for missing identity mappings: the assistant should withhold restricted material until it can establish permission. A model instruction is not a substitute for this application behavior.

Some integration decisions are difficult to add later. Google’s Agent Search documentation currently describes access control as a preview feature requiring identity-provider configuration; an existing data store cannot have its access-controlled setting switched on or off. That makes identity and access part of the initial source design. Verify the actual product, connector, and release you plan to use before estimating implementation effort.

Check the changes a connector can miss

The phrase “supports permissions” is too broad for a source approval. Ask what happens when access changes on a single document, an inherited folder, a site, or a group. Those changes may take different paths through the same product.

Microsoft’s SharePoint indexer documentation gives a concrete distinction. Starting with the documented 2026-05-01-preview API, changes to unique item permissions are detected during successful indexer runs. Permission changes inherited from a parent site, library, list, or folder require an explicit refresh mechanism. A working individual-file test would not establish the inherited-permission behavior.

Create a small change inventory for the source and assign an owner to every manual refresh dependency. If an everyday administrative action needs a separate operation in the assistant, put that operation in the administrative procedure. A dependency without an owner can become stale state. The acceptance check should exercise how your team really administers the source, including failures during those updates.

Define what removal actually removes

Deleting a document in its original repository and removing its indexed representation are separate operations. Establish how the connector detects deletion, which job applies it, and what evidence confirms completion. Include failed or interrupted synchronization in that procedure.

Amazon Bedrock’s documentation says additions, changes, and removals require a data-source sync, which processes changes incrementally. It also exposes ingestion-job status and document statistics. Use those observations to investigate a deletion that has not reached the knowledge base; accepting a job request alone does not show the required result.

Keep retention decisions explicit. Removing material from future retrieval may be a different requirement from deleting historical conversations, exported answers, backups, or audit records. Assign those copies their own owners and deletion rules. The source approval should identify which copies the assistant creates and which systems remain outside its control, so a removal request has a complete operational path.

Include answers that skip fresh retrieval

A repeated question may be answered from a cache. An ongoing conversation may already contain earlier material. Review these paths alongside the search index, because improving the latest retrieval query leaves other stored representations to govern.

OWASP’s RAG guidance recommends scoping response caches by the relevant user, tenant, and permission context, and invalidating entries when source content or access changes. A cache lifetime chosen only for speed does not establish that the cached answer is still appropriate for its reader.

Write down how your application associates an answer with the sources and permissions it depended on. Use that information when deciding whether an old answer can be served again. Define historical conversation behavior separately from new generation, and test shared conversation links with the recipient’s identity. An access change cannot retract information someone already read, but the application can control what it exposes on subsequent requests.

Approve sources with evidence

Exercise changes with permitted and denied users. Confirm that a revised document replaces the old answer, revoked access stops new disclosure, restored access works again, and deleted material disappears from the relevant retrieval paths. Check citations and cached responses as well as the visible answer. Preserve the measured result and the configuration tested.

OWASP’s authorization guidance recommends defining permissions from requirements, validating requests, and testing enforcement. Apply that discipline to each newly connected collection. If a source cannot meet its agreed conditions, narrow the supported questions or keep it outside the assistant until the missing behavior is resolved. Give the owner an approval record that includes the following decisions.

The questions the collection should support and its authoritative owner.

The intended audience and identity mapping.

Content, permission, and deletion propagation requirements.

The behavior during stale data, outages, or unresolved access.

The observations and tests supporting the release decision.

A practical next step

Select one proposed source collection. Agree on its audience, content freshness, permission propagation, and removal requirements with its owner. Test those changes in the actual integration before expanding access. Keep the approval record current when the connector or administrative process changes.