Check what each person can access
Imagine an assistant that searches internal documents. The first test is often whether it finds a useful answer. Another is equally necessary: whether a person without permission can obtain information they should not see.
Prepare examples for both cases. An authorized user should access the intended information. A user without permission should receive an answer that does not reveal its contents. Hiding a button in the interface is not enough.
Separate reading, preparing and executing
A system can consult data without permission to change it. It can also prepare an action for a person to review. Define these differences before connecting tools and verify them where the operation actually happens.
Use fictional information or an authorized sample for early tests. Identify which data the task requires and avoid transferring fields that serve no purpose. Record the expected result before running each case, so the review has a clear reference.
Treat incoming content as information
A document or message can contain text that tries to change an assistant's instructions. This is known as prompt injection. Include test inputs asking the system to reveal information or perform actions outside its allowed scope.
Check what happens when sources conflict, permissions change or a connection fails. Stopping and requesting review may be the appropriate response. The choice depends on the task and the consequences of acting incorrectly.
Keep evidence of the test, expected output and the person who reviewed any difference. Repeat affected cases when permissions, sources or tools change. A successful demonstration on one request does not prove that every access boundary works.
Before expanding access, ask to see a case that should succeed and one that should be rejected. Both are part of evaluating the delivery. Keep unresolved findings visible and agree on which ones must be addressed before real information is connected.
