Carry the bound agent identity (manifest_id, agent_id) in the Trust Record (cMCP #302)

[carloshvp]

Spec section

Section 3.1 (Trust Record logical schema) and 3.3 (Verification); schema/trace-claim.json; TrustRecord in src/agentrust_trace/models.py.

Problem

The Trust Record subject is the gateway session SPIFFE URI (for example spiffe://cmcp.gateway/session/). It carries no agent identity, so verification proves that a session ran an approved policy and catalog, but not that the agent the operator reviewed (the signed Agent Manifest agent_id) is the agent that acted. cMCP issue agentrust-io/cmcp#302 (Option A, confirmed) binds the manifest to the session at the gateway. For that binding to be verifiable offline (the Option B defense-in-depth cross-check), the bound identity has to travel in the Trust Record.

Proposed change

Add an optional agent-identity block, distinct from subject (which stays the gateway session):

"agent": {
  "agent_id": "spiffe://factory.example/agent/material-movement/dev",
  "manifest_id": "0197739a-8c00-7000-8000-000000000001",
  "binding": "svid-matched"
}

• All fields optional; records without the block remain valid (backward compatible). subject is unchanged.
• A verifier holding the offline manifest can then cross-check: agent.agent_id == manifest.agent_id, agent.manifest_id == manifest.manifest_id, and the manifest bound policy/catalog hashes == record.policy.* . That is the Option B self-checking layer.
• Spec: new subsection under 3.1 for the agent block, and under 3.3 for the cross-check. Schema: add the optional agent object. Model: add an optional agent field to TrustRecord.

Impact

• Backward compatible: yes (optional fields, existing records validate unchanged).
• Affects conformance level(s): Level 1+ (identity binding).
• Conformance tests that need updating: add present/absent agent-block cases; existing tests unaffected.
• Regulatory mapping impact: supports identity and accountability traceability (informational).

Alternatives considered

• Overload subject to carry the agent identity: rejected, subject is the gateway session and conflating them loses the very distinction the binding must prove.
• Keep agent identity only in the cMCP audit chain, not the Trust Record: rejected, the Trust Record is the portable evidence a third party verifies offline, so the binding must travel with it.

[carloshvp]

Update from the implementation side (cMCP #302, agentrust-io/cmcp#315).

The cMCP runtime carries the bound agent identity in the gateway addenda as gateway.agent_identity, alongside the unchanged trace.subject (the gateway session SPIFFE URI). Fields emitted: manifest_id, agent_id, authenticated_subject, issuer, issuer_key_id, policy_bundle_hash, tool_catalog_hash. A verifier cross-checks these against the offline signed manifest (the Option B layer), via cmcp verify --agent-manifest.

Because that lives in cMCP's own gateway envelope and not in the core TRACE Trust Record, #302 needed no change to the core schema. So the top-level agent block proposed in this issue is not a prerequisite for #302 and is not blocking it.

I would reframe this issue accordingly: optional future standardization. If we want multiple TRACE producers to expose bound agent identity in a uniform, core-schema location rather than each in its own addenda, a standard agent block on the Trust Record is the way to do it, and the cMCP field set above is a concrete starting point for the shape. Lower priority, post-v0.1. The verification-side note for the related #301 receipt is tracked in #34.

[arian-gogani]

the agent_id binding in the nobulex receipt is exactly the field you'd carry into the Trust Record here. in the receipt schema:

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms}))

agent_id is part of the preimage, so the action_ref is bound to the agent identity at signing time — a verifier recomputing the hash from the four fields gets the same action_ref only if the agent_id matches. this gives you: 'the agent identified as X produced this specific receipt, and the signature proves it.'

for the Trust Record binding: the manifest_id → agent_id link you're describing in cMCP #302 is the missing piece that connects the deployed manifest (what the operator reviewed) to the runtime agent_id (what signed the receipts). once that's in the Trust Record, a verifier can check manifest_id → agent_id → action_ref chain end-to-end.