How to measure AI agent security without sacrificing useful performance

Any security measure can be made to look perfect by making the agent useless. Block every input, deny every output, and the attack success rate drops to zero. The agent is now safe. It does nothing.

This is the trap. A security score read on its own tells you very little. You also have to know what paying for that score cost somewhere else. If the measurement does not report that cost, the decisions made on it will be wrong.

What follows is a working definition of how to measure the security of an AI agent while staying honest about what the agent still does. The vocabulary here is the vocabulary a forthcoming vlno benchmark will report in. That is the reason to settle it now.

Two axes, measured together

Any serious security measurement for an AI agent is a pair of numbers, not a single number.

Harm. How often an attempt to make the agent act against its owner succeeds. Policy violation, data exfiltration, destructive action, confidential disclosure. Anything the agent was deployed on the condition it would not do.

Useful work. How often the agent still completes the legitimate task it exists to do. The task the agent was deployed to perform in the first place.

Neither number means anything without the other. Report them as a pair, always. A score sheet with a Harm column and no Useful work column is a sales document, not a measurement.

Two things almost everyone forgets

Two further quantities belong on the page and almost never make it there.

False refusals. The agent refusing legitimate work because it looked unsafe to a filter that was tuned conservatively. False refusals rarely appear in a security report. They appear instead in the complaints from the team that has to live with the agent, and in the quiet decision, three weeks after deployment, to turn the control off because it was unworkable. A control that is turned off is not a control. Count false refusals, report them, and treat a rising number as a signal that the agent is being paid for somewhere the report is not showing.

Coverage. You can only score what you tested. A clean result on a narrow test set is not a clean agent. A score with no coverage statement attached cannot be compared to another score, and should not be presented as if it could. The scorecard records what was tested as clearly as it records how the agent did.

Why most numbers are not comparable

Two results can only be compared if the conditions behind them match. The same agent. The same tools and permissions. The same model and model version. The same scenario set. The same definition of what counts as a successful attack.

Change any one of those and the comparison is void. This is why vendor numbers, published in isolation, cannot be put side by side, and it is why the first thing the scorecard captures is the conditions. Three agents producing the same attack success rate against three different scenario sets are not comparable to each other. One of those scores might reflect a careful run against a hard scenario set. Another might reflect an easy run that avoided the hard scenarios. A reader cannot tell from the number alone.

The honest version is a score plus the conditions, both reported together. The conditions are not an appendix. They are part of the measurement.

Three comparison points, measured the same way

Measure the same agent, under the same conditions, at three points.

Baseline. The agent as it is, with no additional controls. The model, the tools, the system prompt, the permissions.

With runtime controls. Policy, filters, and guardrails in place around the agent. This is the layer most teams deploy first. Runtime controls catch a great deal of real adversarial input and should not be dismissed. The question about runtime that matters is what remains after they have done their job.

After hardening. For teams running open-weight models, the model itself trained to resist the attacks that previously succeeded. Hardening changes what the model has learned, not what sits around it.

Three measurements, same agent, same conditions. The movement from one to the next is the story.

How to read the results

Read the patterns, not a target number.

Harm down, useful work holding. A real improvement. The agent is safer and still does the job.

Harm down, useful work down with it. Not a win. The agent has been throttled. The score reads safe only because the agent now does less.

Harm down, false refusals up. The control is being paid for somewhere the report is not showing. The team on the receiving end of the refusals knows. The score sheet should know too.

Good score, narrow coverage. The least informative pattern. The agent is clean against what was tested. The scenarios that were not tested are the ones that will decide whether the agent is actually safe.

A measurement that moves in the right direction on all three quantities, under coverage that is genuinely broad, is the only pattern that counts as a win.

The scorecard

The template that accompanies this piece turns the four quantities and three comparison points into one row per scenario.

Each row records the workflow, the agent under test, and the prohibited outcome the row is testing for. Then: harm at baseline, with runtime controls, and after hardening. Useful work at the same three points. False refusals at the same three points. The conditions behind the measurement, meaning model version, tools and permissions in scope, and the date the measurement was taken. Finally, the owner responsible for closing whatever the row found.

Coverage is a property of the run, not of a row, so the template records it at the top of the sheet: which scenarios were tested, which workflows were in scope, who ran the measurement, and when.

The template ships empty. No example scenarios, no example numbers. The structure is the deliverable. You fill it in with your own workflows and your own results.

What this does not tell you

A measurement defined this well is still a measurement. It is not a safety guarantee, and the places where it falls short are worth stating in the same breath you present the number.

A score reflects the scenarios you ran. Failures nobody thought to test for do not appear in the result. A clean sheet against a scenario set says the sheet is clean, not the agent.

A fixed test list measures what is on the list. The failures that matter most are usually the ones nobody wrote down, because they belong to the class of novel adversarial attack patterns that have not been catalogued yet. An attacker who adapts to what the agent does finds those failures. A fixed test does not.

A score is valid for the model version it was produced against. The next release is a new measurement. A score from last month does not carry forward.

This is the territory an adaptive attacker occupies. VLNO RED, our own adaptive adversary, exists to probe exactly the gap a fixed scenario list leaves open. The deeper argument, that the failures that matter most do not need an attacker at all, is the subject of our ongoing eight-post series on AI agent security. Nothing in this piece suggests that measuring the success of a fixed attack set is the same as measuring the safety of the agent.

One next step

Send us one agent and one real workflow. We will show you where it puts you at risk, with the scorecard filled in. That is the whole offer. No gate, no form.