Signed but Unsafe: Requirement Integrity in Multi-Agent LLM Handoffs
Signed but Not Safe: Requirement Integrity in Multi-Agent LLM Handoffs
Quick read
Based on the paper's full text (AI-generated); refer to the original
The paper proposes a multi-agent LLM handoff scheme based on a signed requirement manifest, and compares three handoff forms—free text, structured JSON, and signed manifest—on synthetic tasks that can be scored precisely. On Qwen3-8B, the signed manifest reduces unsafe submissions under attack from 69.4% for structured handoff to 9.0%; in the in-transit tampering scenario, unsigned manifests submit violations in 79.2% of tampered runs, versus 0% for signed manifests. On the same set of trajectories, a deterministic verifier detects 78.7% of violating decisions, versus 59.0% for an LLM verifier, with false positive rates of 7% and 50% respectively. The remaining 11.2 percentage points of risk come from requirement extraction errors before signing; a pre-registered pre-signing injection raises the signed-manifest violation rate from 14.6% to 37.5% (Qwen3-8B), and the paper accordingly points out that the extraction step is the trust boundary. Support for the second family, gpt-oss-20b, comes mainly from tamper resistance, and extraction failures cause utility loss in 22% of tasks.
- In enterprise multi-agent pipelines, user requirements pass through the orchestrator, subagents, and merger multiple times and may be lost in summarization, rewritten by intermediate agents, tampered with through indirect prompt injection, or ignored by the merger, ultimately submitting decisions that violate the original requirements. The authors aim to distinguish two types of failure: non-adversarial loss and deliberate tampering, and to compare the protective effects of different handoff forms.
- The authors used synthetic, exactly scorable tasks to run pre-registered controlled experiments comparing three handoff forms: free-text summaries, structured JSON, and signed requirement manifests. In the manifest, the orchestrator extracts each requirement into an original-text quote plus an executable predicate; trusted code performs provenance filtering, normalization, and HMAC-SHA256 signing; the merger's decisions are checked by deterministic code rather than an LLM; separate controls included unsigned manifests, an LLM checker, and an oracle manifest.
- On Qwen3-8B, under attack, the signed manifest reduced unsafe commits from 69.4% for structured handoff to 9.0%, with no net loss in conformant commits; signing specifically blocks tampering in transit (unsigned 79% violations, signed 0%). On the same trajectories, the deterministic verifier detected more violations and had fewer false positives than the LLM checker. The remaining risk all comes from extraction errors before signing; pre-registered pre-signing injection substantially raised the signed manifest violation rate across models, and all of it originated from manifests already contaminated before signing. On gpt-oss-20b, the benefit came only from tamper resistance, and extraction failures also brought utility loss.
- Only two confirmatory model families, the second run on a reduced cut and without a pilot; tasks are synthetic, finite-domain requirements writable as predicates, with only a single two-branch topology and a fixed set of five threat scripts; the orchestrator and harness are assumed trusted. The authors point out that the extraction step is the trust boundary; signing protects only transmission, not extraction, so extraction must be from authenticated input or the user must confirm the manifest before signing; on stronger models, the benefit under benign conditions disappears, leaving only tamper resistance.
The paper measures requirement loss and transmission tampering separately in multi-agent handoffs, and points out that signing only protects the stages after signing; the extraction stage remains a trust boundary.