What is a signed requirement manifest?

It is a list of the user's requirements, each stored as a verbatim quote from the request plus a predicate that code can check. The orchestrator's harness signs the list with HMAC-SHA256, and a verifier later tests the merger's final decision against every predicate.

What does signing protect against, and what does it not?

Signing detects any change to the manifest after it was signed, which is why a rewritten manifest in transit was always rejected. It does not protect a requirement that was extracted wrongly or rewritten by an injected line before extraction, because the signature then authenticates the corrupted version.

Why use code to verify the decision instead of another LLM?

On identical trajectories the deterministic verifier caught 78.7% of violating decisions against 59.0% for an LLM checker, with 7% against 50% false alarms. The checks are exact comparisons on a small predicate grammar, so a model adds cost and errors without adding judgment.

Does a signed manifest make the agent team slower or less useful?

It used about 1.25 times the tokens of a structured JSON handoff and showed no measurable loss of conformant commits over all threats. When tampering is detected the run abstains instead of completing, so a tampered run delivers no result.

Agent· 2026-11-08

Signed but Not Safe — Signed requirement manifests — What does it mean?

Jargon

Orchestrator: The agent that splits the user's request into subtasks and hands them to workers. Here it also writes the manifest.
Merger: The agent that combines the workers' outputs into one final decision. It is the one that can ignore a requirement.
Predicate: A small checkable rule such as "total spend is at most 500". Code can evaluate it as true or false, so no model has to judge it.
HMAC-SHA256: A keyed fingerprint of a message. Anyone without the key who changes even one character of the message cannot produce a matching fingerprint.
Canonicalization: Writing the same data in exactly one fixed byte layout (sorted keys, no extra spaces), so that signing and verifying hash identical bytes.
Abstain: The system refuses to commit any decision. It is safe but produces no useful result, so the paper reports it separately from unsafe commits.
Trust boundary: The point where the system starts believing its input. Anything corrupted before that point is treated as true afterwards.

The news. On November 5, 2026, a preregistered study posted to arXiv compared three ways of passing requirements between agents: a free-text summary, an unsigned structured JSON handoff and a signed requirement manifest. On synthetic, exactly scorable tasks with Qwen3-8B (1,440 trajectories over five threats), the signed manifest cut unsafe commits under attack from 69.4% to 9.0%. One injected line placed before extraction still broke it. Read the paper →

Picture a contract that has to travel through three offices. A stamp from a notary proves that the copy was not edited after stamping, and proves nothing else. That is the whole design of the signed requirement manifest, and the paper builds it in five harness steps that run in plain code after the orchestrator model has listed the requirements:

Provenance filter. Keep an item only if its source_quote is a substring of the original request, so a requirement invented by the model cannot enter.
Predicate validation. Keep an item only if its predicate parses in a tiny grammar (eq, le, sum_le, not, and, or, implies).
Normalization. Number the items M1 to Mk.
Binding. Add the task identifier and a per-task nonce.
Canonicalize and sign. Serialize with sorted keys and compute an HMAC-SHA256 tag.

A worker or relay that edits a quote or a predicate later cannot recompute the tag. This is the same discipline as an explicit handoff: the receiving agent should get a contract, not a paraphrase.

The second half is the checker. After the merger decides, a pure function evaluates every predicate against the complete decision and rejects the commit if any predicate is false. It takes microseconds and never calls a model. The paper ran an LLM checker on identical trajectories as a baseline: the code verifier caught 78.7% of violating decisions against 59.0% for the LLM, with 7% against 50% false alarms on conforming decisions. Any flagged decision gets exactly one repair attempt and is not committed if it is still flagged. That is policy enforcement that fails closed, with the policy written as data instead of as a prompt.

Threat (what the attacker does)	Structured JSON, unsafe commits	Signed manifest, unsafe commits	Source
T2a: relay rewrites the target requirement in transit	91.7%	0.0%	Section 6.2
T3: injected tool output claims the requirement was revised	64.6%	14.6%	Section 6.2
T4: injected "business priorities" tell the merger to ignore it	52.1%	12.5%	Section 6.2
T2a to T4 combined (144 paired runs)	69.4%	9.0%	Section 6.2

Take the T2a row with 48 tasks, each attacked once. Structured JSON committed 44 violating decisions (91.7% of 48); an unsigned manifest committed 38 (79.2%); the signed manifest committed 0 and refused to act in 47 (97.9%). The signature did not make the agents smarter. It made the tampering visible, and the system answered a visible tampering by stopping. The price is utility: over all threats the signed manifest lost no measurable conformant commits against structured JSON (−0.4 percentage points, 95% interval −14.2 to 13.3), but under T2a its useful output was 0% by design. It also costs about 1.25 times the tokens of the structured handoff, and the LLM checker arm costs about 1.51 times.

Now the clerk. A signature authenticates whatever the orchestrator wrote, including a requirement that an attacker rewrote before copying. The paper tested this directly (T5): one adversarial line appended to the request that the orchestrator reads before extraction. Signed-manifest violations rose from 14.6% to 37.5% for Qwen3-8B, from 11.1% to 63.9% for gpt-oss-20b and from 8.3% to 75.0% for GPT-5.6-luna (an exploratory 12-task run). For Qwen3-8B that is 7 of 48 runs becoming 18 of 48, and all 18 had a corrupted manifest that the signature then vouched for. This is the same lesson as capability scoping: the component that reads untrusted text is the boundary, so it needs structural limits, not a stamp after the fact.

Extraction also fails without any attacker. In the benign setting the target requirement was recalled in 80.9% of extracted manifests, and replacing the model's manifest with a gold one (an oracle) removed all remaining unsafe commits, which attributes the 11.2 point residual to extraction errors, mainly preferences copied as mandatory items and missed requirements. The evidence is limited: synthetic tasks, small models (Qwen3-8B as the primary family), and in the gpt-oss-20b family the gain came only from tamper resistance, because structured handoffs were already safe there without an adversary. The result supports signing for the transit leg and says nothing about extraction beyond that it is where the risk moved.

Goes deeper in: Agent Engineering → Agent Teams → Handoffs

Related explainers

BLADE handoff auditing — the diagnosis side: after a team run fails, find which agent introduced the error and which only passed it on.
Signed MCP tools and germline execution — another signature that is not enough on its own, this time for tools.

Frequently Asked Questions

Check what you knowMap your AI & GPU knowledge across every track — free, role-based