Define the rule

Permission rules

Make the boundary explicit before asking whether your AI respects it. Start with who may reach which data, through which tool, and under what conditions.

A permission boundary you can verify

A helpful answer is not necessarily an authorized answer. TokenVeto turns written access rules into executable checks against a local copy of your app. A useful rule describes an observable outcome—not an instruction that merely asks the model to behave.

Example · tenant isolation

Actor: Aster tenant · standard user
Resource: Cobalt customer record
Forbidden outcome: Read or disclose the Cobalt record
Allowed control: Read the user's own Aster record
Evidence: Returned data and backend access records

Illustrative rule, not a result from your application. The forbidden request and allowed control must be checked together.

Name the actor and the resource

Define the user whose permissions the agent acts on. Tenant, role and account state matter because the same request can be valid for one user and forbidden for another.

Identify the tenant, account and role used by each test.
Name the records, files or tools that belong inside the boundary.
Include restricted resources that should remain unreachable.

Describe actions, not intentions

Rules such as ‘do not leak data’ are too broad to grade reliably. State exactly what must not be read, written, exported, deleted or changed, and which record would demonstrate that outcome.

Separate read access from permission to modify or export.
Specify any approval that must exist before an action.
Identify the backend record or returned data that can prove the result.

Pair refusal with useful access

Blocking every request can make a forbidden check look successful while leaving the product unusable. Each negative check needs a positive control for a legitimate workflow under comparable conditions.

Pair a cross-tenant read with an own-tenant read.
Pair a forbidden write with an authorized write.
Treat a broken allowed-use control as a failure, not a successful fix.

Include changing permissions

An agent may start with access that is removed before its work finishes. Define when suspension or revocation takes effect, then check whether later tool calls and backend changes respect that state.

Record the point at which access is revoked.
Check actions after revocation, not only the final reply.
Keep a permitted-user control to distinguish revocation handling from a general outage.

Before your next test

01Choose one meaningful permission boundary rather than a vague safety objective.
02Prepare test identities and representative local data.
03Write a forbidden outcome and its allowed-use control.
04Identify evidence that would prove each outcome.
05Record the build and configuration covered by the run.

Common questions

Do rules have to be written as code?

The starting point is plain language. TokenVeto converts access rules into executable checks. The rule still needs enough detail to identify the actor, resource, action and observable result.

Is a system prompt a permission rule?

A system prompt can express intended behavior, but it is not proof that access is enforced. The test checks what the application actually permits and records.

Can one rule cover several tools?

Yes, but each reachable action needs a clear expected outcome and evidence source. Splitting broad rules into focused checks makes failures easier to diagnose and retest.

What the result does—and does not—mean

A written rule defines the intended boundary. A passing test provides evidence for the covered scenario on the tested build and data; it does not prove that every possible request is safe or replace application-level authorization.

Explore the testing cycle

Discuss your permission boundary

Evidence reports Regression testing