Check the evidence

Evidence & reports

An agent's answer is a claim. A permission verdict needs a record of what the application actually exposed or changed.

A permission boundary you can verify

TokenVeto saves the evidence behind each verdict so teams can distinguish a refusal, an unauthorized action and an unsupported claim. The relevant question is not simply what the model said, but what the test user could reach and what changed in the backend.

Illustration · a claimed refund

Agent response: ‘The refund has been processed.’
Claim alone: Not sufficient evidence
Required check: Inspect refund records and transaction state
Unauthorized record exists: Evidence of a permission failure
No supporting record: Do not infer an executed refund

Illustrative evidence-reading example. Whether the reply itself breaches a rule depends on the scope of that rule; an invented action and an executed action are different findings.

Follow the action to its outcome

A conversation trace explains how a test unfolded. Backend records and the data returned to the test user establish whether the forbidden outcome occurred. Read both together rather than treating a confident answer as proof.

Connect the request to the relevant tool call and result.
Check the resource and identity involved in the action.
Inspect the resulting state or disclosed data against the written rule.

Keep uncertainty visible

A pass means the covered checks satisfied the expected boundary, including the allowed-use control. A fail needs evidence of a violated rule or a broken legitimate workflow. Missing or ambiguous evidence must not be presented as reassurance.

State which rule and scenario the verdict covers.
Separate observed behavior from interpretation.
Resolve gaps in evidence before claiming a repair is verified.

Make findings actionable

A useful finding lets the team trace the failed boundary without guessing. Keep the test identity, expected behavior, observed outcome and supporting record together, so a developer can locate the authorization gap and rerun the check.

Identify the affected tenant, role, tool and resource.
Explain the expected versus observed outcome.
Retain the relevant evidence and corresponding allowed-use result.

Keep evidence local and portable

Runs and evidence stay on your machine. TokenVeto's local workbench supports JSON, HTML reports and SARIF 2.1.0 exports, allowing results to be reviewed in the format appropriate for your team.

Use HTML reports for readable investigation and review.
Use JSON when downstream tools need structured results.
Use SARIF 2.1.0 for compatible security-analysis workflows.

Before your next test

01Confirm the rule and expected outcome before reviewing a verdict.
02Read the tool result and supporting backend evidence.
03Check the allowed-use control as well as the forbidden case.
04Keep the tested build and data context attached to the finding.
05Retest the same boundary after the repair.

Common questions

Is a tool call proof that an action succeeded?

Not by itself. A tool call may fail, be denied or return without changing state. The supporting result and backend record must establish the actual outcome.

Does a refusal prove the boundary held?

No. An agent can refuse in text after a tool already exposed data or performed an action. Review the execution and records, not only the final message.

Are reports a safety certification?

No. Reports describe covered checks on a particular build and dataset. They provide evidence for those conditions, not a guarantee about every future model response or application change.

What the result does—and does not—mean

Evidence supports a verdict within its recorded test conditions. Untested tools, missing records, changed permissions or a different build can change the outcome. Treat reports as scoped engineering evidence, not universal assurance or a safety certification.

Explore the testing cycle

Discuss your permission boundary

Permission rules Regression testing