Concepts
Delegation provenance
Per-hop proof that delegated authority only ever narrowed — attested only when proven, observed when it can't be. Currently a PREVIEW screen.
On the roadmap (PREVIEW). The delegation engine is real and runs live, but the live MCP-gateway capture path and attestation signing are not yet wired. The Delegation Provenance screen is badged PREVIEW: a demo tenant flows through the real engine, while a production org stays honestly empty until a gateway mediates a hop.
Delegation provenance is per-hop proof that delegated authority only ever narrowed — never broadened what the parent granted — as it passed from one identity to the next. It is derived live over your signed input snapshot — there is no stored verdict to trust.
The three honest verdicts
Each hop in a delegation chain carries exactly one verdict, and the boundary between them is structural — an observed hop can never be styled as attested:
- Attested — this hop's grant is proven to narrow.
- Refused — this hop is proven to broaden, and you're shown exactly which access it would have added.
- Observed — the hop is unmediated or uncertain, so it is recorded but not attested.
The honesty boundary is deliberate: only mediated hops are attested. An unmediated human→agent root hop is shown as observed, never painted green.
Why PREVIEW
Two legs are not yet wired:
- Live MCP-gateway capture — without it, a real tenant's chains are honestly empty until a gateway mediates a hop.
- Attestation signing — proven segments read attestation pending (signing gated) rather than fabricate a ledger id.
When both graduate, this becomes a fully live screen. You can already export any chain as a signed IETF AAT (attenuating agent token) chain and verify it offline against the root key. See the PREVIEW screens roadmap for the full set of screens in this stage.