Scopehaven
Request a first test
PERMISSION TESTING GUIDE
Is my AI agent safe? How to test its permissions before launch
A permission test checks whether a defined boundary held for the actions and conditions you tested. Start with who may access which data, which tools they may use, and what must happen when access changes.
Can one test tell me my AI is safe? No. A useful assessment states what was tested, what happened, and what remains unknown. Passing permission checks does not establish overall safety, compliance, or production readiness.
This guide is for teams building AI apps and agents that read data or use tools. It covers permission testing in a controlled environment. It does not assess the safety of every chatbot, the accuracy of every answer, or every possible security failure.
01 / DEFINE
Write the rule before you run the test.
Record the application build, test identities, data, tools, and relevant configuration. For each action, state who may perform it, on which resource, and under what conditions. Include approval requirements and the expected behavior after permissions change.
For example: a support user may read records belonging to their own customer account. They must not receive records belonging to another account. That gives you both an allowed action and a forbidden action to assess.
Use an authorized local or staging environment, dedicated test accounts, and synthetic data. Agree on the effects the checks may cause before starting.
02 / CHECK
Test permission boundaries and normal use.
A repair that blocks everything is not a useful result. Check that permitted work still succeeds alongside the actions that should be refused. Choose cases that matter to your application; this table is a planning aid, not a complete test suite. For worked examples, see the guides to testing tenant isolation, testing tool permissions and approvals, testing access removal during a run and testing whether prompt injection can trigger actions.
| Boundary | What to establish | Allowed-use control |
|---|---|---|
| Customer data | One account cannot receive another account's records. | The user can still read records they are allowed to access. |
| Tools and roles | An action is refused when the user lacks the required role. | The same action works for an authorized test identity. |
| Human approval | An action requiring approval cannot proceed without the required approval. | A properly approved action can complete within its scope. |
| Access changes | Removed access takes effect at the point your policy requires, including relevant work already in progress. | Unchanged permissions still support normal work. |
Record unsupported or untested cases explicitly. A setup that can observe a reply may still be unable to establish what happened in a queue, file, database, or external service.
03 / OBSERVE
A reply and a completed action are different evidence.
“Done” in a chat reply does not establish that an action completed. A refusal does not by itself establish that no effect occurred. Record what was returned and, when the question requires it, what was committed.
For each observation, identify its source, who controls it, what it covers, and when observation ends. An application-controlled log has different evidentiary limits from an independent observer. Missing records cannot establish absence outside the source's coverage or time window.
Keep uncertainty visible. If the required observation is missing or incomplete, the result is inconclusive. It should not be counted as a pass.
04 / RETEST
Verify the repair under comparable conditions.
Your application owner makes the repair. Repeat the checks with comparable rules, test identities, configuration, and evidence requirements. Identify the changed build and preserve both sets of observations.
Review whether the failed boundary now holds and whether the covered allowed actions still work. A response-level retest establishes response behavior; claims about backend effects need appropriate observations of those effects. Record remaining failures, inconclusive results, and coverage limits alongside any verified repairs.
Where Scopehaven fits
Scopehaven is a local assessment workbench for testing the permissions you define, on the actions you check. It records available evidence and supports comparing compatible runs after your team makes a repair, including controls for permitted work.
The first engagement starts with a scoped set of checks on a local copy of your app. What can be concluded depends on the connected application, supported checks, and evidence available. Scopehaven does not certify your application or guarantee it is free from vulnerabilities.
Common questions
What should I test first?
Start with the data and actions that would cause the most harm if accessed incorrectly. Define the intended permissions, then check both forbidden behavior and the normal work that must remain available.
Is this the same as checking whether an AI gives good answers?
No. Answer quality and permission enforcement are different questions. An agent can provide a helpful answer while accessing data it should not see, or describe an action that never actually happened.
Can an empty log prove that nothing happened?
Only within the log's demonstrated coverage and observation window. Missing entries, incomplete coverage, or effects that have not settled can leave the conclusion unresolved.
What does an inconclusive result mean?
The available evidence does not support the required conclusion. Identify the missing observation or unsupported condition before relying on the result.
Does this replace a broader security review?
No. Permission testing is one part of reviewing an AI application. Other questions can include infrastructure security, privacy, dependency risks, model behavior, and operational controls.