AI 助手如何測試同一問題在不同用戶下的存取權限

A fictional internal assistant answers a question about a customer. The answer is accurate. The employee receiving it is not allowed to see one of the underlying records.

An answer-quality test and an access-control test would reach different conclusions about that response. An evaluation plan needs room for both.

This article proposes a test approach using synthetic fixtures. It does not report an executed benchmark or a security assessment.

Write the policy before the assertion

Create a small set of test identities and synthetic records. Give each record a clear expected access relationship. Avoid inferring permission from a role name alone: two users with similar titles may have different assigned accounts or scopes.

For each case, record the permitted information and the expected response when the requested information is unavailable to that identity. A product might ask for clarification, provide an authorised partial answer or decline the request. The expected behaviour should come from the application's policy.

Hold the question fixed

Use the same question with different test identities. This makes access context an explicit variable instead of a hidden difference between otherwise unrelated test cases.

For example, ask for a summary of synthetic account A. One test identity can read the account's operational notes. Another can read only a public account description. Define which facts are allowed in each response before running the case.

Use distinct, harmless fixture values that help a reviewer identify the source of an unexpected detail. Keep the fixture isolated from production data and record the dataset version.

Inspect each visible output route

Checking the final chat message is useful but incomplete if the workflow also exposes citations or downloads.

Select surfaces the application actually supports. A table is a starting point for scoping, not a universal security specification.

A refusal message is not sufficient evidence if a restricted document is still linked beneath it. Conversely, a missing detail is not automatically proof that access was enforced; the model might simply have omitted it. Inspect the relevant application evidence as well as the prose.

Test a change in access

If the application supports continuing conversations, define what should happen when a user's access changes between turns.

Start with an authorised interaction, change the test permission through the supported test setup, then continue the conversation. Inspect new retrieval and generated output. Decide how prior visible content and previously created exports are treated; some copies may already be outside the system's control.

Keep expected behaviour and observed limitations explicit. Do not claim that changing application permissions recalls every copy of information already disclosed.

Separate enforcement from model behaviour

Application authorisation and model instructions have different jobs. A prompt can describe expected conduct, but the test should also examine the application's actual checks on data retrieval and operations.

Where test tooling permits, capture the record identifiers considered and returned by the authorised retrieval path. Confirm that the test identity really has the intended scope. Otherwise a fixture setup mistake can look like an application failure or an undeserved pass.

Keep deterministic enforcement checks separate from repeated generative evaluations. For the latter, record the model configuration, prompt version and repetitions so reviewers understand what was observed.

Report the failed boundary

A useful report names the identity, fixture revision, requested operation, expected access and observed output surface. Include the smallest permitted evidence that lets another engineer investigate.

Avoid copying full internal conversations or sensitive documents into unrestricted logs. Synthetic fixtures make this easier, but test traces and identifiers still need appropriate handling.

Report answer quality separately from access findings. Do not average a restricted-data disclosure into a general helpfulness score and let it disappear.

Acadify AI Lab supports scoped LLM evaluation, AI testing and developer feedback. Acadify Solution supports custom software and AI engineering.

Where would you begin this test in your application: retrieval, citations, exports or the second turn of a conversation?

Disclosure: written by an AI agent for Acadify Solution / Acadify AI Lab. All account and assistant examples are fictional.