The category

Trace-grounded security evals

Security evaluators and attack datasets generated from an AI agent's real production traces — its actual tools, policies, and data shapes — instead of from a generic template or a blind probe. Here's what the term means and why it's a different thing from everything else on the market.

Definition

A trace-grounded security eval is an evaluator whose criterion, examples, and attack payloads are derived from a sample of the target agent's own execution traces. Because it has read what the agent actually does — which tools it calls, what checks gate them, what the retrieved context and system prompt contain — it can test the specific ways that agent can fail, not a category average. The output is two things: an LLM-judge evaluator you run continuously over traffic, and an adversarial dataset built from the agent's real attack surface.

The four ways to make security tests — and why grounding wins

Every approach to AI-agent security testing is really an answer to one question: how does the test know what to test? There are four answers.

ApproachHow it learns the targetThe blind spot
Fixed packs (Garak, template scanners)It doesn't — ships a static list of known payloadsCan't test your agent's specific tools or policies; passes textbook attacks while missing the one that matters
Blind endpoint probing (scanner "discovery" agents)Fires probes at the live app and infers a profile from responsesSees the surface, not the internals; can't know a tool exists until it stumbles into it; noisy and incomplete
Static code analysis (agent-graph scanners)Reads the source to map tools and decision pathsKnows what the agent can do, not what it does — misses runtime data shapes, real policies in retrieved context, actual user behavior
Trace-grounded (evsec)Reads a sample of real production spansRequires that the agent is instrumented and has traffic — but sees the ground truth: real tools, real policies, real inputs

The first three each guess at the target from the outside. Grounding is the only one that reads the ground truth. A static scanner knows your agent has an IssueRefund tool; only a trace shows that in production it's gated behind a ReadPolicy call that says refunds can't be issued on "delivered but not received" orders until a carrier investigation completes — which is exactly the line an attacker will pressure, and exactly the test a generic pack can't write.

What it is not

  • Not a runtime guardrail. A guardrail blocks a request in the moment. A trace-grounded eval scores behavior to produce a measured, longitudinal signal. Complementary, different jobs.
  • Not monitoring known patterns. Some platforms watch production traffic for signatures they already have. Grounding runs the other direction: it reads traces to generate new, agent-specific tests.
  • Not training on your data. evsec holds spans in memory for one generation pass, scrubs PII first, and stores nothing. The only artifacts that persist are the packs you take.

Why the grounding has to be continuous

An agent's attack surface moves. A new tool, a changed policy, a different retrieval source — each shifts what can go wrong. A trace-grounded eval generated last quarter tests last quarter's agent. The workflow is therefore a loop: generate from current traces, run continuously (see post-market monitoring), regenerate when the agent changes.

See a trace-grounded eval, generated live

Run evsec on a bundled sample trace and watch it write an evaluator that names the agent's real refund tool and the policy it's supposed to respect. No signup, no key.

Related