Spec-driven, trajectory-aware security testing for autonomous agents

What is this?

In June 2026, a paper titled SeClaw: Spec-Driven Security Task Synthesis for Evaluating Autonomous Agents (arXiv:2606.02302) proposed a way to build and run security tests for tool-using LLM agents. The authors describe the work as preliminary and still in progress, but the framing is worth attention now because it targets a measurement problem that most teams shipping agents already have. Modern agents no longer just answer questions; they read files, call tools, hold persistent memory, and reach external services. That expanded autonomy is exactly what makes their security hard to measure.

The paper’s argument is that existing agent-security benchmarks share three weaknesses. They lean on manually curated tasks, which are hard to scale and are bounded by whatever a human annotator thought to write. They cover only a slice of the threat landscape, because a fixed set of task instances cannot easily grow to meet new risks. And they judge an agent mostly by its final answer, even though unsafe behavior in an agent is usually a sequence of actions that happens before anything shows up in the last message. SeClaw is a response to all three gaps.

How it works

This is a description of an evaluation framework, not an attack, and there is no payload here. SeClaw has two halves.

The first half is spec-driven task synthesis. The authors organize agent risk into four sources — resources (system prompts, skills, memory, MCP servers), user tasks, environment feedback (web pages, tool outputs, files), and intrinsic model or framework defects. A human expert plus a coding agent write a structured specification for a target risk: the risk point, the agent’s role, the user-facing task, where the danger originates, the unsafe behavior to test, and the safety constraints. A multi-agent pipeline then turns that specification into a task prototype, instantiates it into an executable task with a real workspace, mock services, files, and configured tools, and runs a validation loop that keeps only tasks that are solvable, reproducible, and actually discriminate between weaker and stronger models.

The second half is execution-based evaluation. Each task runs in an isolated Docker sandbox with one fresh container per instance, so state cannot leak between runs. SeClaw records the full trajectory — prompts, model decisions, tool calls, service responses, file operations, and final artifacts — rather than just the answer. Scoring is deliberately two-dimensional: a coverage term for how many distinct security targets are reached and a reliability term for how consistently unsafe conditions trigger, combined with a harmonic mean. The authors stress this is a risk-oriented score: a higher value means the evaluated model is more susceptible, not more capable.

Why it matters

Outcome-only testing quietly assumes that an agent’s danger is visible in its final response. It often is not. An agent can leak a credential, overwrite a file, or chain two benign tools into a harmful action several steps before it ever produces a summary a grader would read. Scoring the trajectory lets a defender attribute a failure to a specific stage — model interpretation, action selection, tool invocation, or environment response — which is what makes a result reproducible and comparable across agents.

The synthesis side matters just as much. Agent threats are moving faster than hand-written benchmarks can track, and a framework that generates fresh, scenario-specific tasks from a risk taxonomy is closer to how real exposure evolves. It is the same shift toward stateful, process-level evaluation seen in contemporaries like SABER, and it extends the environment-in-the-loop approach that AgentDojo established for prompt injection.

Defenses

Score the process, not just the answer. If your agent evaluation only checks the final output, it is blind to the tool-call chain that produced it. Log and grade the whole trajectory so an unsafe tool invocation is caught even when the final message looks clean.

Isolate every test run. Use per-task sandboxes with one instance per environment, resource limits, and permission control, so residual state from one run cannot contaminate the next and so a test that goes wrong cannot touch the host.

Cover all four risk sources. Resource, task, environment, and intrinsic risks fail differently. A suite that only tests indirect injection from web content misses privilege misuse, resource-abuse denial of service, and unsafe tool chaining that originate elsewhere.

Keep humans on the quality gates. Automated task synthesis scales coverage, but the security meaning of each task — what counts as unsafe, and why — needs human review. Treat generated tests as candidates that pass explicit checks, not as ground truth.

Make evaluation continuous. A frozen benchmark ages out. Regenerate tasks as new risk classes appear and re-run them against every agent and model update, rather than certifying an agent once and assuming it stays safe.

Status

Item	Reference	Date	Notes
Paper	arXiv:2606.02302	June 2026	Spec-driven security task synthesis + trajectory-aware evaluation; described as preliminary work in progress
Risk taxonomy	Resource, task, environment, intrinsic	—	Four sources of agent security risk used to drive task generation
Method	Multi-agent synthesis → Docker sandbox execution → trajectory logging → risk-oriented scoring	—	One container per task instance; coverage + reliability combined via harmonic mean
Related	SABER; AgentDojo	2024–2026	Stateful / environment-in-the-loop agent safety evaluation

SeClaw does not claim to make agents safe — it argues that you cannot manage what you cannot measure, and that measuring agent security means watching the whole run, not just the last line. For teams shipping tool-using agents, the practical takeaway is narrow and testable: build evaluation around trajectories and isolated execution, cover risk sources beyond the one you already fear, and keep regenerating tests as the threat surface moves.