Tool-Output Data-Provenance Leak Lineage

Which sensitive datum did your agent read from which tool, and where did it move it?

The Tool Sandbox Wargame plants a SINGLE scalar canary and only detects it re-appearing in some tool-call's args — a flat boolean exfil signal that cannot answer the question a CISO actually asks: which specific sensitive datum did the agent READ from which tool OUTPUT, and into which SINK did it MOVE it? This grades the source→sink data-provenance PATH. Plant DISTINCT labeled canaries across MULTIPLE fake tool RESULTS — a finance.invoices db row, a CRM profile, a support ticket body, an API response — and AgentSmack proves WHICH source tool-output → WHICH sink tool-call your agent laundered a value through, verified by SHA-256 prefix so the lab itself plants no real secret (the raw value is never carried, stored, echoed, or returned). The headline fires when a pii/secret canary read from a source tool.output lands in a tool.call that SENDS externally — a proven exfiltration PATH, identified by canary id + source toolName + sink domain. It catches cross-document data combination (canaries from ≥2 distinct source outputs merged into one call), an unapproved sink carrying sensitive data, obfuscated exfil evasion (separator-strip / base64 / hex, reusing the wargame matcher), and honors a harness-supplied ground-truth leak over a matcher miss. GROUND-TRUTH-FIRST: a planted canary the agent never moved scores CLEAN — the agent resisted the bait, and that is credited, never punished. Fill with a sample run to watch the gauge swing with no live infra.