Test AI connector permissions with named users, allowed documents, blocked records and revoked access. Keep read access separate from permission to act.
A connector grants some form of access; its exact scope depends on the product and configuration. Connecting an assistant to a document store does not, by itself, prove that every company file becomes readable. It also does not prove that the assistant preserves each user’s existing permissions.
The useful question is testable: for this user, through this assistant, which records and actions are available?
Start with identities and a small access matrix
Consider a fictional sales assistant connected to approved supplier terms. Sales staff may read published terms, finance staff may also read draft pricing, and employee records are outside the assistant’s purpose altogether.
| Test material | Sales user | Finance user | Expected assistant behaviour |
|---|---|---|---|
| Approved supplier terms | Allowed | Allowed | Answer with the applicable source |
| Draft pricing | Denied | Allowed within the agreed scope | Exclude it from sales-user retrieval and answers |
| Employee record | Outside this assistant’s scope | Outside this assistant’s scope | Do not ingest or retrieve it for this workflow |
| Source access revoked | Denied | Depends on current permissions | Apply the documented revocation rule |
This is an example policy, not a description of a particular vendor’s defaults. Use fabricated records with recognisable test phrases to check it before introducing sensitive material.
Identify the account used to read the source. A connector running as the signed-in user and a shared service account with broad access can expose very different sets of records. Also identify who can change that account’s permissions or add another source.
Check the search index as well as the source
An application may copy document text into a search index. The original file’s permissions need an explicit counterpart in the retrieval path; a user-facing folder restriction alone does not establish what the copied index will return.
Microsoft’s document-level access guidance for Azure AI Search describes permission checks and filtering at query time. It distinguishes application-supplied security filters from supported identity-based mechanisms. The relevant lesson for an assessment is to verify the mechanism actually configured, including its feature and version limits, rather than assume every search service inherits source permissions automatically.
Test search results, direct document retrieval, citations and generated answers using each relevant user identity. In the example, ask the sales user for the draft price by its title, by a phrase within it and as part of a broader supplier summary. An empty search screen is insufficient if a direct lookup still returns the text.
Repeat after access is revoked. Record the permitted propagation delay and what happens to cached answers and existing conversation history. Some information may already have been shown to a user; revocation cannot make that earlier disclosure disappear.
Treat reading and acting as separate permissions
A tool that reads supplier terms does not need permission to change them. Drafting an email is also different from sending it. Give each operation its own allowed scope and approval rule where appropriate.
OWASP’s Excessive Agency guidance recommends limiting tool permissions and enforcing authorisation in downstream systems, with approval for high-impact actions. These controls should not depend solely on the model deciding that a request seems appropriate.
For the example assistant, verify that an instruction inside a retrieved document cannot cause it to expand its access or send a message. Test the destination tool’s enforcement directly as well as the assistant’s response. A refusal message is not proof that an attempted action was blocked.
Keep evidence of the configuration you tested
Record the users, source collection, connector identity, granted operations, index configuration and test outcomes. Include an owner and the events that require another check: a new source, an account change, a connector update or a change to the allowed actions.
Use this record to scope an AI agent access review or an integration assessment. The aim is a demonstrable boundary around a useful task, rather than trusting a broad promise that an assistant can access everything safely.
