Raised by @l33tdawg in agentrust-io/.github discussion #15 while taking the SAGE integration in-consensus. Opening it here so the work is tracked rather than leaving him to file it.
Problem
A RuntimeClaim's cnf is the gateway's TEE-sealed key (_build_cnf(signing_key), subject spiffe://cmcp.gateway/tee/<prefix>). The agent rides in gateway.agent_identity, which carries manifest_id, agent_id, authenticated_subject, subject_source, issuer, issuer_key_id, policy_bundle_hash, and tool_catalog_hash.
It does not carry anything identifying the agent's own signing key.
That blocks a legitimate downstream pattern: a consumer that wants to check, deterministically and offline, that the party which signed some downstream artifact is the agent the claim describes. In SAGE's case every validator wants to evaluate thumbprint(on_chain_author_pubkey) against the claim, with no network call.
The two obvious workarounds are both wrong:
- Export the gateway's sealed key so the agent can sign with it. This defeats the point. The claim asserts that a signature came from inside a measured runtime; a key that can be handed to a caller no longer supports that assertion.
- Compare against
cnf, which is the gateway key, so it answers a different question than the one being asked.
Proposal
Add an optional field to agent_identity, something like:
agent_key_thumbprint: str # "sha256:<hex>" over the agent's signing public key
The gateway already authenticated the agent, so it is the correct party to attest that binding. The thumbprint sits inside a payload signed by the TEE-sealed key, so a verifier who appraises the claim chain gets the agent-key binding for free, and non-exportability is preserved because only a hash leaves the enclave.
Additive and backward compatible: existing consumers ignore it, and claims without it stay valid.
Open questions
- Digest form.
sha256:<hex> for consistency with the rest of the claim, or a JWK thumbprint per RFC 7638 for consistency with cnf.jwk? RFC 7638 is arguably more correct for a key, and interoperates with anything already handling cnf.
- Where the gateway learns the key. Agent Manifest binds the agent's signing identity, so
manifest_id may already be enough to resolve it. If so, this field is a convenience that saves a lookup rather than new information, which is still worth having for an offline validator but changes how we describe it.
- Optional or required at a conformance level. Leaning optional, since not every deployment has an agent key distinct from the gateway.
Note
There is a path that works today without this: the agent signs with its manifest-bound key and the verifier checks that key against the signed manifest record. This issue is about making the binding available from the RuntimeClaim alone, which is what an in-consensus check needs.
Raised by @l33tdawg in agentrust-io/.github discussion #15 while taking the SAGE integration in-consensus. Opening it here so the work is tracked rather than leaving him to file it.
Problem
A RuntimeClaim's
cnfis the gateway's TEE-sealed key (_build_cnf(signing_key), subjectspiffe://cmcp.gateway/tee/<prefix>). The agent rides ingateway.agent_identity, which carriesmanifest_id,agent_id,authenticated_subject,subject_source,issuer,issuer_key_id,policy_bundle_hash, andtool_catalog_hash.It does not carry anything identifying the agent's own signing key.
That blocks a legitimate downstream pattern: a consumer that wants to check, deterministically and offline, that the party which signed some downstream artifact is the agent the claim describes. In SAGE's case every validator wants to evaluate
thumbprint(on_chain_author_pubkey)against the claim, with no network call.The two obvious workarounds are both wrong:
cnf, which is the gateway key, so it answers a different question than the one being asked.Proposal
Add an optional field to
agent_identity, something like:The gateway already authenticated the agent, so it is the correct party to attest that binding. The thumbprint sits inside a payload signed by the TEE-sealed key, so a verifier who appraises the claim chain gets the agent-key binding for free, and non-exportability is preserved because only a hash leaves the enclave.
Additive and backward compatible: existing consumers ignore it, and claims without it stay valid.
Open questions
sha256:<hex>for consistency with the rest of the claim, or a JWK thumbprint per RFC 7638 for consistency withcnf.jwk? RFC 7638 is arguably more correct for a key, and interoperates with anything already handlingcnf.manifest_idmay already be enough to resolve it. If so, this field is a convenience that saves a lookup rather than new information, which is still worth having for an offline validator but changes how we describe it.Note
There is a path that works today without this: the agent signs with its manifest-bound key and the verifier checks that key against the signed manifest record. This issue is about making the binding available from the RuntimeClaim alone, which is what an in-consensus check needs.