C=US Hardware Signing Scorecard← White House accord scorecard

Hardware identity · narrow-scope follow-up

What a hardware-backed signature actually buys you — and what it doesn't.

This project provisioned a real YubiKey PIV key (private key generated on-device, never exported), used it to sign a real XAdES-BES XML document (ETSI EN 319 132-1, ECDSA-SHA256 per RFC 4051, via NIST SP 800-73-4's on-device signing operation), and issued it a certificate from a self-signed root asserted by this project's own steward. The signed document and a diagram of the full trust chain are both public: attestation-log.xml and trust-chain-diagram.svg. This page asks a narrower question than "is this secure": specifically, how much does hardware-backed, non-repudiable signing move the needle on the ten agentic-AI risks this project has been scoring all session?

Answer, up front: not much, and precisely. This isn't a disappointing result to soften — it's the correct, honest shape for what a signature mechanism can and can't do. A signature says who signed what and when. It says nothing about whether an agent's output is safe, where its network traffic goes, or whether it's coordinating with other agents. Jev's scores below reflect exactly that boundary.

Method

Same split as every other scorecard on this site

Claude wrote the description of the hardware-signing mechanism and every risk/rubric; Jev returned every score below, given that fixed state.

WHAT CLAUDE CODE DID
  • Built the actual mechanism first: provisioned the YubiKey PIV slot, wrote the NIST SP 800-73-4 signing bridge, registered a custom XAdES-BES/ECDSA-SHA256 algorithm under RFC 4051's real URI, and verified every signature cryptographically before writing anything about it.
  • Described that real mechanism precisely to Jev — what it hardens (key-theft resistance, non-repudiation, a named root of trust) and, just as importantly, what it explicitly does not touch (sandboxing, egress, inter-agent coordination, output validation).
  • Reused the identical ten risks and 0-3 rubric already used for the White House accord and Anthropic's Constitution, for direct comparability.
WHAT JEV DID
  • Given that fixed description, scored all ten risks and the direct comparison verdict — nothing here is Claude's guess at what the numbers "should" say.
  • Model version, full question text, and token usage are preserved in research/jev-hardware-signing-score.json in this project's repository.

Result

Sharply differentiated, not a flat score

0 = not addressed by this hardening · 3 = substantially addressed by this hardening alone.

Third-party attribution blindness
2.40
Unaccountable agent identity
2.18
Privilege chaining / excessive agency
1.67
Emergent multi-agent coordination
1.33
Detection lag / cross-agent blindness
1.29
Human over-reliance, no approval gate
1.08
Unapproved egress / SSRF
0.59
Goal drift beyond task boundary
0.55
Indirect prompt injection
0.50
Insecure, unvalidated model output
0.33

It scores highest on the two risks that are fundamentally about traceability — exactly what non-repudiation targets — and lowest on risks about model output, prompt injection, and network egress, which key custody has nothing to say about. That's the mechanism working as designed, not a weak result.

OVERALL VERDICT

Asked directly whether hardware-backed signing meaningfully improves the broad agentic-risk picture (not just the identity-specific slice), Jev returned 1.00 out of 2, confidence 0.92.

3%
94% · a marginal improvement: real but narrow
3%

What this checked, and what it found

The mechanism is real, not a demonstration of the idea of a mechanism

A genuine on-device ECC P-256 keypair, a genuine XAdES-BES signature structure, a genuine certificate chain — every claim is independently verifiable against the published signed document, not merely asserted.

Hardware non-repudiation is a real but narrow fix

It closes the specific gap between "a software key that could be copied off a compromised host" and "a key that provably never left a physical device" — genuinely valuable for identity and attribution, genuinely silent on everything else.

It is not a substitute for capability constraints

The full c=US architecture (identity, authorization, and sandboxing together) scored 1.99 out of 2 on the same kind of verdict question, against the risks that actually matter most for a swarm. Hardware signing alone reaches half that. Both belong in the design; neither replaces the other.

Sources and underlying data

What this page draws on