feat(provenance): make a refusal evidence, and demo it

[imran-siddique]

The gap

enforce_peer_call raised on an over-scoped call and emitted nothing. A denial left no artifact, so an auditor walking the DAG saw a gap where a hop should be, and the only account of why the call stopped was the operator's log. For a project whose pitch is "a third party can check this without trusting you", the refusal was the one thing you had to take on trust.

What changed

A refusal now emits a linked provenance record carrying the requested capability, the effective scope it fell outside, and the reason, attached to ScopeNotPermitted.record. The call still fails closed; the record is evidence, not a way to continue.

• verify_dag treats a denial as terminal: nothing may be chained onto a refused hop, so a trail cannot claim work proceeded.
• cross_check_chain matches only hop records positionally against the chain, and still requires a denial record to name a credential that is actually in it, so a refusal cannot be attributed to authority never granted.
• ca2a verify-dag reports outcome: denied with the requested capability and effective scope, instead of printing verified: true and burying the interesting part.
• Denial fields are omitted from an allow record's hashed body, so existing allow-record hashes are unchanged. Committed DAGs keep verifying.

The demo

examples/rejection-with-proof/. An agent asks for authority nobody delegated to it, is refused, and the refusal verifies offline through the shipped CLI against the committed chain and DAG.

ALLOW  tool:search    effective scope ['tool:search']
DENY   tool:purchase  capability 'tool:purchase' is not in the effective scope

{"verified": true, "records": 4, "outcome": "denied",
 "requested_capability": "tool:purchase", "effective_scope": ["tool:search"],
 "cross_checked": true}

The callee's local policy permits tool:purchase on purpose. It is refused anyway because the delegated scope does not carry it, which is the distinction transport-layer auth cannot express. A demo where the callee simply did not support purchasing would prove nothing.

The demo runs in CI (tests/unit/test_example_rejection_with_proof.py) so the README cannot promise something the code stopped doing, and both the README and the module docstring state that it makes no attestation claim: no sealing, no peer attestation, nothing about where the code ran.

Test plan

• pytest tests/ — 205 passed, 2 skipped; 6 pre-existing test_cedar.py failures unrelated to this change (they fail identically on a clean tree and pass in CI)
• ruff check clean
• Demo run end to end, including the reparent-tamper check at the end

🤖 Generated with Claude Code