Closed World Does Not Transfer
Cars, aircraft, medical devices, and trading systems assign accountability through pre-certified products, statutory liability, and internal logs read after an incident.
Open AI agents are different: software-only, continuously updated, multi-provider, and cross-organizational. The verifier may have no prior relationship with the agent operator.
Key difference the verifier needs live evidence for this action, not an internal black-box record for later investigators.
The Weld
The bench binds an AEP receipt hash, TPM quote over H(outcome + nonce), Veraison EAR appraisal, and MachineMandate SD-JWT VC into one action-time presentation.
The proposed AgentRuntimeEndorser trusted-list role is the missing authorization surface for issuers that make agent-runtime claims.
What We Can Show
- RATS/EAR verdict carried as claims inside a MachineMandate SD-JWT VC.
- OpenID4VP request binds presentation to verifier nonce and audience.
- Relying party re-derives freshness and quote binding from raw quote bytes.
- Issuer accepted only if listed under a proposed AgentRuntimeEndorser role.
The Privacy Problem
Naive accountability makes an agent easy to follow. The same proof that helps a verifier reject replay, scope abuse, and runtime substitution can also reveal stable identifiers, software lineage, mandate structure, and repeated action patterns.
PETS angle accountability must be scoped, pairwise, and minimally disclosing.
Privacy Boundary Map
Verifier Must Learn
- Mandate covers this action.
- Presentation is fresh and audience-bound.
- Runtime appraisal is affirming.
- Endorser is authorized for agent runtime claims.
Verifier Should Not Learn
- Global agent identity across contexts.
- Reusable model or policy fingerprint unless necessary.
- Unrelated scope and mandate structure.
- Status-check metadata that reveals activity history.
Correlation Surfaces
| Surface | Risk | Possible Boundary |
|---|---|---|
| Agent subject | Cross-verifier tracking | Pairwise or sector-specific pseudonyms |
| Software identity | Model lineage fingerprint | Commitment or class proof instead of raw name |
| Action hash | Repeated task linkage | Domain-separated, nonce-bound commitments |
| Status and revocation | Issuer observes presentations | Offline status lists and cached freshness windows |
| Endorser role | Trust list becomes activity map | Role discovery separated from per-action telemetry |
Bench Evidence
What Gets Denied Where?
| Layer | Accepts | Denies |
|---|---|---|
| Layer 1: SD-JWT VC / KB-JWT | Issuer signature, disclosure, nonce, audience | Forgery, disclosure mismatch, replay at presentation layer |
| Layer 2: RATS/AEP weld | Fresh affirming attestation bound to action | Stale quote, EAR swap, contraindicated appraisal |
| Layer 3: Trusted list role | Issuer listed as AgentRuntimeEndorser | Wrong service type or unlisted issuer |
| Layer 4: Mandate scope | Action inside delegated scope | Confused-deputy overreach |
Questions For PETS
- What is the minimum disclosure set for per-action accountability?
- Can runtime identity be proven as a class property rather than a stable identifier?
- How should status freshness work without leaking presentation events?
- Can trusted-list discovery remain separate from per-action telemetry?
- Where should selective disclosure stop and zero-knowledge proofs begin?