Where would collaborator input be most useful right now?

[madeinplutofabio]

Hi all, thanks for adding me to the AgentTrust collaborators team.

I’ve started going through the repos, commented on the TRACE key-revocation issue, and opened a small PIC Standard addition for the awesome-ai-governance list.

My work on PIC is focused on local-first pre-execution action gating: intent, provenance, evidence verification, trust sanitization, approval boundaries, and high-impact tool-call governance.

Before I go deeper, I’d like to align on where contributions would be most useful for AgentTrust right now: spec review, implementation feedback, conformance/security edge cases, integrations, or something else.

I want to contribute in the direction that helps the project rather than adding noise.

[imran-siddique]

@madeinplutofabio really appreciate the framing. Directional alignment is worth more than volume, so this is exactly the right question to ask.

1. TRACE key revocation: design, not just review

You've already found the hardest open problem in the spec. TEE-sealed signing keys break the standard revocation mental model: you can't revoke a key that was sealed to a specific enclave measurement without invalidating every TRACE record that key signed, including legitimate past records. We need a design that distinguishes "revoke future issuance" from "invalidate historical records" and anchors that distinction in the SCITT ledger without requiring a trusted revocation oracle. If this intersects with your PIC provenance verification work, I'd like to explore that thread directly.

2. Pre-execution intent as a TRACE claim

Your PIC work sits exactly adjacent to a gap in the TRACE profile. Right now TRACE records what happened at runtime. It doesn't capture declared intent before execution, which is precisely what your pre-execution action gating, intent verification, and approval boundary work addresses. There's a natural bridge: a pic_intent EAT claim in the TRACE record that references a PIC-compliant intent declaration, making the attestation record complete in both directions (before the call + after the call). If you're willing to co-author that claim definition, I think it belongs in the TRACE spec as a first-class optional field.

3. Conformance test edge cases around high-impact tool calls

The 197 Agent Manifest conformance tests are thin on approval boundary edge cases, specifically: what constitutes a valid HITL approval record, escalation chains, and multi-party approval for high-impact tool calls. Your governance work on approval boundaries is directly applicable. A handful of well-specified edge case tests here would be higher value than many general ones.

4. Awesome-ai-governance: keep going

The PIC Standard entry is genuinely useful. The list needs more entries that represent approaches that are structurally different from the mainstream policy-as-YAML pattern. PIC qualifies.

Short version: key revocation design + the PIC/TRACE bridge are where you'd move the needle most. Happy to jump on a call to walk through where the spec currently stands on both.

[madeinplutofabio]

Thanks Imran, this is exactly the kind of direction I was hoping for. I'm in on the two you flagged.

PIC/TRACE bridge (pic_intent): yes, I'd like to co-author this.

Right separation of concerns: TRACE covers the runtime/attestation record; PIC covers the pre-execution intent, provenance, evidence, and authorization decision. A pic_intent field/claim binds the two so the record is complete in both directions: what was declared and authorized before the call, and what actually ran.

Since the Trust Record schema sets additionalProperties: false at the top level, pic_intent would be added as a defined optional field rather than an ad-hoc claim. So this is genuinely a spec + schema change. I think that is the right home for it.

First-cut shape to react to (field names are placeholders; the binding rule is the substance):

"pic_intent": {
  "profile": "PIC-ATT/1.0",
  "decision": "allow",
  "tool": "payments_send",
  "impact": "money",
  "args_digest": "...",
  "intent_digest": "...",
  "claims_digest": "...",
  "provenance_ids": ["approved_invoice"],
  "evidence_ref": { "uri": "...", "digest": "sha256:..." },
  "sig": { "alg": "ed25519", "key_id": "...", "value": "..." }
}

Two notes on the shape:

1. sig represents the trusted signer's Ed25519 signature over the canonical PIC declaration, separate from the record's cnf binding (§3.2.2). It is what proves an independent authority or trusted evidence source authorized the intent rather than the runtime self-asserting it. In PIC today, the signature sits in the evidence-entry wrapper around the attestation object; carrying or referencing it here preserves that independent-authorization property.
2. decision is a proposed bridge/profile addition. PIC's signed attestation object does not carry the verifier verdict today (allow / block is the verifier output), so we would need to define how the decision is surfaced and whether it is bound into the signed bridge artifact or referenced alongside it.

The binding rule is the value: a verifier resolves the tool-call transcript via tool_transcript.transcript_uri (integrity guaranteed by tool_transcript.hash) and checks the executed call against pic_intent.tool and pic_intent.args_digest, proving the call that ran is the call that was declared and authorized beforehand. Since tool_transcript is optional in Phase 1 and required in Phase 2+, the full before/after binding lands at Phase 2+.

Alignment worth noting: PIC-CJSON/1.0 builds on RFC 8785 (JCS), the same canonicalization base TRACE uses, so the digest/signature boundary is compatible without a new canonicalization layer.

One scoping note: pic_intent is specifically pre-execution authorization intent (does this action proceed, given verified evidence), which keeps it in the lane above the runtime record that TRACE leaves open. There is active IETF work in and around this space, so I'm happy to map pic_intent against your §7 AIIP open question and make sure it complements the adjacent agent-intent work rather than overlapping it.

Key revocation: happy to take this as design work.

This lines up with the gap LIMITATIONS.md already names: existing records remain cryptographically valid after signing-key compromise, and transparency log integration is the required control. Your "revoke future issuance vs invalidate historical records" framing maps onto what I sketched on trace-spec#46: anchor the revocation window to the SCITT inclusion time rather than the record's self-asserted iat, which a compromised key controls.

"Revoke future issuance" becomes: reject any record whose verifiable transparency-log inclusion time is at or after revoked_time, while records included before it stay valid.

One dependency to make explicit: this assumes the TRACE SCITT profile exposes a verifiable registration/inclusion timestamp on the receipt. docs/verification.md currently treats the receipt as proof of inclusion and immutability, not as a trusted clock, so part of the design is pinning the receipt's registration time as the anchor.

For records with no usable receipt or no verifiable inclusion time, there is no trustworthy anchor, so the safe fallback is binary revocation: reject all records from that key. Distributing revocation as signed statements anchored in the same SCITT log keeps verification offline (per §3.3, "no callback to the issuer") and avoids a trusted online oracle.

Happy to turn that into concrete spec text.

Conformance / approval boundaries

I can contribute a small, focused set later around HITL approval records, escalation chains, and multi-party approval for high-impact calls. I'd rather keep the bridge and revocation threads as the first focus so I don't spread the work too thin.

A call sounds good. I can bring a written pic_intent rough first draft so we have something concrete to react to.

[imran-siddique]

@madeinplutofabio This is exactly the right level to start from — a few reactions before we get on a call.

pic_intent shape

The structure is right. Three things to sharpen:

1. decision binding. You correctly note that PIC's signed attestation object doesn't currently carry the verifier verdict — allow/block comes out of the verifier, not the authorization artifact. I'd define decision as part of the bridge artifact and require the sig to cover it explicitly. The verifier then checks sig, confirms the trusted signer is authorized to make authorization decisions for the given tool/impact pair, and treats decision as an attested judgment — not a self-assertion from the runtime. This removes the ability for a compromised runtime to self-assert an allow verdict while carrying a valid-looking pic_intent block.

2. Digest inputs. Since PIC-CJSON/1.0 and TRACE both anchor to RFC 8785 JCS, I'd specify args_digest as JCS of the canonical TRACE tool_call block → SHA-256, and intent_digest as JCS of the canonical PIC declaration → SHA-256. Keeps the chain explicit: intent digest in the bridge artifact, tool-call digest in the bridge artifact, receipt in the SCITT log.

3. Schema composition. pic_intent should $ref a separate pic-intent.schema.json rather than embedding PIC's type definitions inline in trace-claim.json. Keeps the TRACE schema composable and lets the PIC schema version independently. I'll open a draft PR against the schema once we agree on field names.

Key revocation — sequence number vs. timestamp

Your SCITT inclusion-time framing is right directionally. One refinement: SCITT inclusion timestamps carry clock trust assumptions (the notary's clock), while sequence/entry IDs are purely monotonic and cryptographically bound to the Merkle structure. I'd propose revocation references a last_valid_entry_id in the log rather than a wall-clock timestamp, with revoked_after as informational. This also keeps full verification offline without synchronized clocks.

Your point about pinning receipt registration time is the right design dependency to surface — verification.md currently treats the receipt as inclusion proof, not trusted clock, and that needs to be a normative requirement in the SCITT profile section before the revocation design can land cleanly.

Call structure

Bring the pic_intent draft and your revocation sketch from #46. I'll have the current trace-claim.json constraints and the SCITT profile requirements mapped out so we can write actual normative spec text in one session rather than circling the design. Drop your time zone and I'll send an invite.