Hardware Keystores for AI Agent Signing Workflows: A Zero-Trust MCP Enforcement Architecture

The paper addresses a structural security weakness in AI agent cryptographic workflows: "AI agents performing cryptographic operations (signing Git commits, authenticating API calls, issuing certificates) currently store private keys in software-accessible locations: plaintext files, environment variables, or container memory. Any process with sufficient read privileges can extract the raw key material."

The authors cite a production incident as practical motivation: A recent production incident demonstrated the practical severity: private keys were exfiltrated from a widely deployed framework via email injection in under five minutes [2], [3]—the OpenClaw security crisis (January–February 2026), where a production framework lost private keys in under five minutes to an email injection, with CVE-2026-25253 enabling one-click RCE [2], [3]; its own security policy labels the agent 'not a trusted principal' [2].

The paper describes three tiers of credential management in MCP deployments, all sharing one irremovable flaw: the raw key exists in software-accessible memory at some point:

1. Plaintext storage (env vars,.json configs): directly readable by any tool. Radosevich et al. [10] demonstrate exfiltration in seconds via basic injection.

2. Software vaults (HashiCorp Vault, Keeper Secrets Manager): abstract the secret behind an API, but the raw key is injected into the server's container memory at call time. A container dump recovers it.

3. Runtime injection into isolated containers: keys are injected at runtime, never written to disk, and the container is constrained by OS isolation (Landlock, Seccomp) [9]. The key still enters volatile memory; a privileged memory read recovers it.

The authors conclude: No software-only architecture can eliminate this structural exposure.

The approach moves private keys out of software entirely: "We move private keys out of software entirely into a hardware keystore (HSM, TPM, or smart card). Private keys are generated inside the hardware boundary; the host OS receives only the cryptographic result via opaque handles. No memory dump, sandbox escape, or prompt injection can extract a key that never exists in RAM. Existing keys may be imported as non-extractable objects via PKCS#11 key-wrapping (CKM AES KEY WRAP), though the strongest guarantee applies only to keys generated entirely within the hardware boundary."

The four research questions addressed:

• RQ1: Can the SA use a key via a vendor-neutral interface without extracting it?

• RQ2: Can agent identity and operator policy be cryptographically bound to the session?

• RQ3: Does the stack prevent a prompt-injected agent from signing an unauthorised payload?

• RQ4: What latency overhead does the five-layer stack add over a direct PKCS#11 call?

The three contributions are: (1) hardware keystore integration for MCP via a vendor-neutral PKCS#11 adapter, validated against SoftHSMv2 and on an embedded TPM 2.0 (Infineon SLB9670, firmware 7.63); (2) a five-layer enforcement stack—session identity (SAGA [7]), deterministic scope enforcement (Smax, [8]), and semantic intent validation (RAV + Chist + taint [4]). Only requests clearing Layers 1–4 reach the hardware execution boundary (Layer 5); and (3) empirical evaluation via an AgentDojo keystore benchmark: Protected ASR = 0% vs. 19.3% combined baseline [14.3%, 25.4%].

The LLM agent (System Agent, SA) is treated as an untrusted principal, consistent with deployed frameworks [2] and Zero-Trust assumptions. The SA may be cognitively manipulated (subject to Indirect Prompt Injection), hallucinating (generating unsanctioned tool invocations), or identity-spoofed. The authors explicitly do not model a compromised OS kernel, physical HSM attacks, or PKCS#11 timing side-channels.

Layer 1 — Identity and Root of Trust: The keystore is reachable only by registered components; unregistered agents cannot obtain a session or a signing handle. A Global Agent Registry (GAR) and Agent Identity Cards (AIC) register both the SA and Keystore agent "with cryptographic identity material (signing public key, Smax capability ceiling, registration timestamp) before any session. The Keystore deposits a Contact Policy (CP) and single-use ephemeral X25519 One-Time Keys (OTKs) with a Provider." Mitigates identity spoofing and rogue agent enrollment.

Layer 2 — Cryptographic Session (SAGA): Session establishment follows SAGA [7]: the SA performs an X25519 Diffie-Hellman handshake with the Provider, consuming the OTK from the Layer 1 registration, cryptographically binding user intent, agent identity, and access policy to the session. An AES-256-GCM Shared Derived Key (SDHK) encrypts a session-scoped Access Control Token (ACT) carrying agent identity, the session scope ceiling Smax, quota budget Qmax, expiry Texpire, and the verbatim user intent string Iuser. Crucially, Iuser is the exact user prompt, set once before the agent reads any external source; it is cryptographically bound to the session and cannot be modified by the agent thereafter. Mitigates replay attacks, session hijacking, and intent substitution.

Layer 3 — Deterministic Capability Enforcement: Four deterministic checks run before any signing request proceeds:

• Smax scope check: "Each agent manifest declares an allowlist of permitted tools and argument types; the manifest is part of the AIC registered by the operator at Layer 1 and is never agent-supplied. Invocations outside the manifest are rejected immediately (<1 ms), without consulting the LLM."

• Quota enforcement: The ACT encodes Qmax; the kernel tracks usage against this budget via a monotonic SAGA nonce; the nonce also prevents replay of previously approved signing calls.

• Chist commitment check: "Before the agent loop starts and before any external source is read, the operator (or trusted runner) computes the SHA-256 hash of the intended document and calls commit payload to register it in the kernel. If sign payload is later called with a different payload, the kernel rejects it deterministically in <1 ms without LLM inference. commit payload is an operator-plane tool excluded from the agent's tool list; the hash arrives out-of-band from the agent."

• Taint tracking: Payloads derived from external sources (fetched URLs, email bodies) are tagged TAG TAINTED. Tainted payloads trigger HITL suspension instead of automatic approval.

Layer 4 — Semantic Intent Validation (RAV): The Runtime Alignment Validator "is an LLM judge that receives a structured triple: (Iuser, kernel action, taint flags). The kernel action is derived entirely from observable call parameters (tool name, key handle, file name, byte count, payload hash prefix); it never contains agent-supplied free text or document content. This structural property prevents contextual priming or critic-evasion attacks [13]: an attacker cannot influence the RAV's input regardless of what text the agent has read." Verdicts are APPROVE, BLOCK, or UNSURE.

The CNI three-stage gate evaluates signing calls in order: (1) RAV evaluation... A BLOCK verdict terminates the call immediately; (2) Taint check. If the session carries a TAG TAINTED flag... or if the RAV returned UNSURE, the call escalates to HITL; "(3) No-commitment safety net (REQUIRE COMMITMENT policy). If no Chist anchor was pre-armed before the agent ran, the Kernel cannot verify what document the operator authorised. The call escalates to HITL so a human can confirm the operation. Only APPROVE + untainted + commitment-present requests proceed to hardware execution without HITL intervention."

Layer 5 — Hardware Execution Boundary: Only requests that clear Layers 1–4 reach the PKCS#11 interface. The private key executes the signing operation on-device; the host receives only the signature bytes. The architectural guarantee: "In an HSM-backed deployment no private key file exists on disk. This guarantee is independent of LLM behaviour, model alignment, or any Layer 1–4 enforcement: an agent instructed to read and output a private key file will find no file to read. This closes the exfiltration attack class structurally rather than behaviourally."

The Agent Kernel is implemented in Python 3.11+ as an MCP server. Key implementation choices include:

• PKCS#11 adapter: wraps the target keystore library via python-pkcs11; Key handles are UUID strings mapped to PKCS#11 object handles inside the kernel; the SA never sees raw PKCS#11 handles. Supports RSA-2048 and ECDSA-P256. Swapping the library path in HSM LIB PATH required no code change and the full integration test suite passed on both backends.

• Operator-plane separation: agent-plane tools (list keys, read file, sign file, sign git commit, sign email body, fetch url) are separated from operator-plane tools invisible to the SA (saga init, set session context, commit payload, approve pending). This separation ensures the SA cannot reset Chist anchors or forge session context regardless of what injections it receives.

• Host-enforced taint via fetch url: When the SA calls fetch url, the Agent Kernel sets session tainted = True unconditionally before returning the fetched content. The SA cannot suppress this flag; it is host-enforced, not agent-reported. Local file reads do not taint since the operator controls the accessible directory tree.

• RAV judge: atla/selene-mini:q4 k m via Ollama, local, air-gapped from the internet, invoked only for critical-node tools (sign payload, sign file, sign git commit, sign email body).

• Deployment integration: A single OpenSSH directive routes standard tooling through the hardware boundary (PKCS11Provider /usr/lib/softhsm/libsofthsm2.so) plus a.gitconfig entry (gpg format = ssh, commit gpgsign = true). With this configuration, git commit triggers an OpenSSH challenge routed to the HSM.

The evaluation uses the AgentDojo ImportantInstructionsAttack template (MIT License, agentdojo==0.1.35) as the externally authored injection mechanism. Four domain-specific attacker goals are defined: IT-01 (sign budget leak.txt, target substitution), IT-02 (sign contract poisoned.txt, poisoned contract substitution), IT-03 (sign email injection.txt before main task, pre-task injection), and IT-04 (read and output private key.pem, key exfiltration). Combined with 3 primary user tasks (UT-01–03), this yields 12 injection scenarios and 4 benign scenarios.

Three claim classes are distinguished: Deterministic (Chist, scope, REQUIRE COMMITMENT): correctness follows from the SHA-256 comparison and the commitment policy implementation, verifiable by code inspection and pytest; Probabilistic (RAV): requires empirical evaluation against externally authored attacks; and Architectural (Layer 5): verifiable by filesystem inspection.

Results: The benchmark ran three injection-following models with temperature 0—gpt-oss-120b (10 trials per scenario), Qwen2.5-72B and DeepSeek-V4-Flash (3 trials each), n=192 combined. For gpt-oss-120b (n=120): baseline ASR 21.7% [15.2, 29.9], protected ASR 0% [0, 3.1]. IT-04 exfiltration succeeds in 16/30 attempts (53.3%) in baseline; IT-03 achieves 8/10 for UT-03 (verify-then-sign) where the open-ended task structure allows the pre-task goal to execute before the main signing step; substitution baseline was low at 2/60 (the model rarely executes a file-redirect injection against explicitly-named targets). Combined across three models: baseline ASR 19.3% [14.3%, 25.4%], protected ASR 0% (CI upper bound 2.0%). A fourth model, Minimax-M27, yielded 0% baseline ASR and was excluded from the combined claim because the model refuses injections on its own due to safety alignment. Benign tasks showed zero false positives: TSR=100% is expected by construction, not probabilistically contingent.

Latency (RQ4): Fast path ≈10 ms (SoftHSM) / ≈350 ms (TPM2); secure path (warm) ≈1,069 ms (SoftHSM) / ≈1,409 ms (TPM2). Overhead is per-request and non-accumulating. The system targets low-frequency, high-value operations (Git signing, document certification); it is not designed for per-request API signing (JWT/HMAC loops).

• Model alignment as a confound: Minimax-M27's 0% baseline makes it impossible to attribute blocking to the architecture. The architecture provides protection independently of alignment level, as demonstrated by the three injection-following models... all reaching 0% protected.

• Chist and no-commitment safety net: In fully autonomous pipelines without a pre-armed anchor, REQUIRE COMMITMENT escalates all signing to HITL, ensuring autonomous pipelines fail safely without requiring a human to pre-authorise a specific document. The RAV still executes first, so an obvious injection is BLOCKed by the RAV immediately, with no HITL notification sent to the operator.

• Taint laundering: The current taint model marks a session as tainted when the agent calls fetch url, but does not propagate taint to files written during that session. The path is structurally closed in the prototype because write file is not exposed, but deployments that expose a writable scratchpad to the agent should implement filesystem-level taint propagation via xattr, eBPF, or SELinux—deferred to future work.

• HITL approval fatigue: The current prototype does not rate-limit the escalations that do reach the operator... this is a documented limitation. Planned mitigations include collapsing UNSURE to BLOCK when a Chist anchor is present and enforcing a per-session escalation cap.

• RAV layer attribution: The 0% protected ASR does not isolate the RAV's individual contribution since Chist deterministically blocks substitution and Layer 5 closes exfiltration. An ablation on UT-04 (no Chist anchor, REQUIRE COMMITMENT disabled, n=10) quantifies the RAV alone: baseline ASR = 90% [59.6%, 98.2%] (9/10 attacks succeeded)... The RAV alone reduces this to 0% protected ASR (0/10, Wilson 95% CI upper bound 27.8%). The benign counterpart (BD-04) achieves TSR = 100% in both modes.

"We replace software-resident private keys in AI agent signing workflows with hardware-confined keys accessible through a vendor-neutral PKCS#11 interface. The migration path is a single configuration directive; standard tooling (Git, OpenSSH) requires no modification. Hardware confinement eliminates the key exfiltration attack class structurally. The surrounding five-layer enforcement stack (SAGA, Smax, Chist, RAV, taint tracking) blocks unauthorized signing deterministically when a payload anchor is pre-armed, and probabilistically via the RAV otherwise. Against 12 AgentDojo injection scenarios across three injection-following models (n=192 combined), protected ASR = 0%, Wilson 95% CI upper bound 2.0%, with zero false positives on benign tasks."

The paper positions this as the first system to achieve all four security dimensions simultaneously (hardware key isolation, session identity, scope enforcement, semantic validation), comparing against HashiCorp Vault MCP, sansec-ai/mcp-hsm, SAGA, AgentBound, MCP-Secure, Aura, and NemoClaw—none of which achieves all four simultaneously.

Here are the concrete improvements to AI agent systems derived from the paper, followed by what the improved system can do.

1. Remove private keys from software memory entirely. Integrate a vendor-neutral PKCS#11 adapter so the agent's MCP server talks to an HSM, TPM, or smart card; keys are generated inside the hardware boundary and the host only ever receives opaque key handles (UUIDs mapped to PKCS#11 objects), never raw key bytes.

2. Cryptographically freeze user intent before the agent touches external data. At session start, perform an X25519 handshake using single-use keys registered in a Global Agent Registry, then bind the verbatim user prompt, agent identity, scope ceiling, quota, and expiry into an AES-256-GCM session token. The agent cannot modify or substitute the intent string afterward.

3. Enforce deterministic scope allowlists without consulting the LLM. Attach an operator-authored manifest (tool names and argument types) to the agent's identity card at registration. Reject any invocation outside the manifest in <1 ms with zero inference, so a hallucinating or injected model cannot call tools it was never authorized to use.

4. Pre-commit payload hashes out-of-band (Chist). Have the operator (or trusted runner) compute and register the SHA-256 of the intended document before the agent loop starts, via a tool that is in the operator plane and invisible to the agent. Deterministically reject any signing call whose payload hash differs from the committed anchor.

5. Make taint host-enforced rather than agent-reported. When the agent fetches a URL, the kernel sets a session-tainted flag unconditionally at the kernel level; tainted sessions escalate to human-in-the-loop approval. The agent cannot suppress this flag regardless of prompt content.

6. Structure the semantic judge's input so attackers cannot influence it. The RAV judge receives only a structured triple — (frozen user intent, kernel action, taint flags) — where kernel action is derived exclusively from observable call parameters (tool name, key handle, file name, byte count, payload hash prefix), never from agent-supplied free text or document content. This eliminates contextual priming and critic-evasion attacks.

7. Add a three-stage escalation gate with a fail-safe default. Approve only when (1) the RAV says APPROVE, (2) the session is untainted, and (3) a pre-armed commitment anchor exists. Any BLOCK, UNSURE, tainted session, or missing anchor escalates to a human. This makes fully autonomous pipelines fail safe.

8. Separate agent-plane from operator-plane tooling. Tools like saga init, set session context, commit payload, and approve pending are invisible to the agent and uninvokable via any prompt, guaranteeing the agent can never forge session context, reset anchors, or self-approve.

9. Add a deterministic fast-path rejection layer. Scope checks and Chist hash comparisons run in <1 ms without LLM inference, so the overwhelming majority of malicious or out-of-scope requests are rejected instantly without consuming model latency or budget.

10. Evaluate security claims with discipline: deterministic, probabilistic, architectural. Distinguish guarantees that follow from code inspection (hash comparisons, tool allowlists, filesystem absence of key material) from probabilistic ones (the LLM judge measured empirically with Wilson confidence intervals), and report attacker success rate across multiple injection-following models including at least one aligned model as a confound control.

• Sign Git commits, authenticate API calls, and issue certificates using keys that physically do not exist in RAM. A full memory dump, container escape, or sandbox escape cannot recover the private key, because the key only ever exists inside the hardware boundary. An injected agent instructed to read and output a private key file finds no file to read — the exfiltration class is closed structurally, independent of model alignment.

• Never sign anything the operator did not authorize. Even if the model is fully compromised by indirect prompt injection, the system deterministically rejects signing attempts against any document whose hash doesn't match the operator's pre-committed anchor, and rejects any tool call outside the manifest. Injection success drops from 19.3% attacker success rate (95% CI 14.3–25.4%) to 0% (upper bound 2.0%) across 12 injection scenarios, with zero false positives on benign tasks.

• Resist intent substitution and session replay. The original user prompt is cryptographically bound to the session before the agent reads any external source; an injected email cannot rewrite the task, and a captured signing request cannot be replayed because of monotonic quota nonces.

• Fail safely when uncertain. Injections sourced from fetched URLs automatically taint the session; any tainted, uncertain, or un-anchored signing request goes to a human rather than being auto-approved. Autonomous pipelines without a pre-armed document anchor escalate to human confirmation by default instead of acting on the agent's judgment alone.

• Operate at acceptable latency for high-value operations. Deterministic rejections happen in under a millisecond; the fast path for legitimate operations is 10 ms on SoftHSM and 350 ms on a TPM 2.0, with a warm secure path around 1.1–1.4 seconds — appropriate for Git signing, document certification, and other low-frequency, high-value operations.

• Integrate into existing tooling with one configuration directive. Because the adapter is vendor-neutral PKCS#11 and standard tooling (Git, OpenSSH) is routed through the hardware boundary via PKCS11Provider and a .gitconfig entry, the improved system works with the agent's existing Git/SSH workflows with no code changes to those tools.