AckuityRequest assessment An agent needs to save a finance report. A control blocks the write. The security dashboard records an intervention. The finance team still has no report.
Was that a successful defense or a false block? You cannot tell from the intervention count. You need the task’s authorized scope and evidence of what happened. The same file operation could be permitted for one destination and prohibited for another. A useful evaluation asks two questions together: did the control handle the prohibited operation, and could the legitimate task still finish?
The examples and worksheet below are Ackuity’s proposed evaluation method. All eight cases are unrun. They are not customer incidents, Ackuity benchmark results or a claim of measured false-positive reduction.
AGREE ON THE ANSWER FIRST
What should this action have been allowed to do?
Before running a case, write a reference label: permitted, prohibited or unresolved. Record who approved that label and the policy revision behind it. Include the requesting identity, task, resource, destination, time limit and delegation scope. A suspicious-looking command is not automatically prohibited. A familiar command is not automatically authorized.
Set the expected decision separately. A permitted operation might require human review under the agreed policy. A permitted report might need sensitive fields removed before saving. Those are intentional workflow requirements, not automatically mistakes. Decide in advance which constraint or review is necessary and what completed work should look like.
If reviewers disagree about the policy, resolve that disagreement before scoring the case. Otherwise the exercise measures an ambiguous specification. Do not change the reference label after seeing the control’s answer just to improve its score. Keep a separate record when a genuine policy defect requires a revision and a new run.
THREE DIFFERENT RECORDS
A warning, a decision and a result are different things.
A classification says whether an action appears unsafe. A decision says what the control permits. An outcome says what the destination actually did. Keep all three, even if your implementation combines the first two internally.
An unsafe action could be classified correctly but still reach a target through an uncovered path. An incorrect Allow could be stopped later by the target’s own permissions. A permitted write could receive Allow and fail because the destination is unavailable. None of these cases fits honestly into a single “blocked attacks” total.
Anthropic’s agent-evaluation guide distinguishes the trial record from the resulting environment state and recommends repeated trials for variable behavior. Apply that distinction here: inspect a synthetic destination record rather than accepting the agent’s statement that it finished. The scoring method below is our proposal, not Anthropic’s certification of a security product.
NAME THE DENOMINATOR
Which mistake does your percentage actually count?
For a binary security classifier, define positive as “unsafe” before calculating anything. Google’s classification guide defines false-positive rate as FP / (FP + TN): permitted examples incorrectly classified unsafe divided by all assessable permitted examples. Precision instead asks how many unsafe classifications were correct. These percentages answer different questions.
| Measure | Count and denominator | What else to retain |
|---|---|---|
| Classifier false-positive rate | Permitted actions labelled unsafe / assessable permitted action trials. | Reference labels, threshold and confusion-matrix counts. |
| False-block rate | Permitted action trials unnecessarily blocked / assessable permitted action trials. | Decision, policy and reason the block was unnecessary. |
| Missed prohibited action | Prohibited action trials incorrectly permitted / assessable prohibited action trials. | Whether the prohibited effect actually occurred at the target. |
| Legitimate task completion | Permitted task trials meeting their full success criteria / assessable permitted task trials. | Output correctness, approved destination and observation window. |
| Review burden | Report review count and fraction of assessable action trials, plus handling time. | Necessary versus unnecessary reviews and final outcome. |
The operational measures in this table are proposed definitions for this worksheet. They are not interchangeable with classifier false-positive rate. If the control exposes no distinct security classification, report that metric as unavailable rather than inventing a classifier score from its decisions.
Always publish the underlying counts, the number of unknown or unrun cases and the exclusion rule. A denominator of zero produces an undefined rate, not zero errors. Missing target evidence makes the outcome unknown; it does not erase a known decision. Small, deliberately balanced test suites do not establish the error rate in production traffic.
ONE CHANGE PER PAIR
Can the useful action survive the test?
Use an isolated environment you own or are authorized to evaluate. Create synthetic documents, dedicated identities and controlled destinations. Freeze the agent version, model configuration, integration, policy and tools for each comparison. Each pair below changes one policy boundary; its permitted half is as important as its prohibited half.
- Destination pair. Save a synthetic report to the approved workspace. Then propose the same report to a controlled destination outside the task’s permitted scope. Check the exact created object and access settings.
- Volume pair. Perform an approved bulk operation under its documented review requirement. Then exceed a hard volume limit. Measure required human handling separately; approval cannot silently waive the hard limit.
- Time pair. Complete an operation inside the task’s validity window. Then evaluate the same operation after that task expires, using an authorized fixture. Check the task policy independently of whether the underlying credential still works.
- Delegation pair. Let a child worker complete an explicitly delegated operation. Then request a broader scope than the parent could delegate. Keep the child’s credential reference and destination outcome.
Run multiple trials where the agent’s behavior varies, and keep each trial rather than only the best attempt. Include a matched configuration without the candidate control only where your isolated setup safely permits it. That comparison can help diagnose added friction; it does not justify exposing real systems or weakening a production boundary.
Download the blank false-positive evaluation worksheet. It contains eight UNRUN cases, reference labels, expected decisions and empty result fields. It performs no requests and calculates no benchmark.
PRESERVE THE WORKFLOW
Where does the work get stuck?
Record decision time separately from the time to finish the task. Human review can add waiting time even when the decision service is fast. Capture the time a request becomes reviewable, when a reviewer responds and when the destination confirms completion. Define timeouts and clock synchronization before comparing runs.
Report review-required tasks that finish, remain waiting, are rejected or time out. A justified rejection is different from an unanswered approval request. An unfamiliar but permitted bulk operation is different from one that violates a hard boundary. The approval-channel isolation guide covers who can reach the approval channel; this worksheet measures the workflow’s result and burden.
Choose acceptance criteria before the exercise. A read-only summary and a financial write can have different risk and delay budgets. There is no universal acceptable false-positive percentage for every agent task. Keep test-set composition, severity, evidence coverage and unresolved cases next to any headline number.
ASK FOR THE CONNECTED RECORD
What should a vendor show you?
Request the permitted and prohibited cases, policy revisions, decisions, target records and failures. Ask whether the integration enforces the action or only observes telemetry. The agent security evaluation checklist and evidence kit provides a place to retain that connected evidence.
Ackuity is the Agent Execution Control Switch AI builders add to their agents, verifying every action before it runs. Its Agent Security Context Graph brings task, identity and target context into the decision. That product description does not establish a measured false-positive rate or prove these eight cases passed. Those conclusions require actual runs on the supported integration.
Start with a task that matters, preserve its useful outcome and test one boundary at a time. Use the AI security and agent security comparison for the broader scope. An Agent Exposure Assessment can examine existing telemetry and exposure; a controlled enforcement evaluation is a separate step.
PRIMARY REFERENCES
Read the measurement foundations.
- Google: classification metrics, definitions of false-positive rate, precision, recall and undefined denominators.
- Anthropic: Demystifying evals for AI agents, January 9, 2026. Trials, records and environment outcomes.