How to let AI agents sign without exposing private keys in 2026

Let an AI agent request a consequential signature without exposing a private key by keeping the key in a hardware keystore and requiring identity, scope, semantic, and taint checks before the hardware signs. The agent can propose an action, but it should not become a signature oracle just because it can produce persuasive text.

The signing boundary should be outside the agent

The paper's central move is to replace software-accessible key storage with a hardware-confined key reached through PKCS#11. A host may ask the device to sign, but the raw private key does not need to appear in host memory. That converts a key-reading problem into a policy-and-execution-boundary problem.

What the proposed enforcement stack adds

Hardware confinement matters, but it is not enough on its own. The authors place session identity, deterministic scope constraints, semantic validation, and taint tracking in front of the hardware boundary. In practical terms: identify the session, bound what it may sign, inspect whether the request makes sense, and refuse to treat tainted context as harmless merely because it has been summarized.

That aligns with a production tool contract: the agent supplies an intent, while an independently enforced boundary validates and records the consequential action. For a private tool surface, the same separation belongs alongside the exposure controls described in private MCP server exposure.

What the paper actually evaluated

The authors report an evaluation using 12 injection scenarios derived from AgentDojo across four LLMs. Their baseline and protected results are useful as a bounded test result—not as a claim that every signing architecture will behave the same way in production.

12

AgentDojo-derived injection scenarios

4

LLMs in the reported evaluation

19.3%

reported baseline attack success rate

0%

reported protected-stack attack success rate

The paper reports a 95% Wilson interval of 14.3%–25.4% for the 19.3% baseline result and an upper bound of 2.0% for the protected result. It also reports zero false positives in four benign task scenarios. Those figures belong to the authors' test setup; they do not erase the need to test the actual commitments, tools, and trust boundaries in your own system.

Use the pattern for the right kind of signing

The authors target low-frequency, high-value operations such as Git signing and document certification. They explicitly do not position the design for per-request JWT or HMAC signing loops. If the workflow is consequential and discrete, the additional policy boundary can be the point. If it is a high-frequency API path, forcing this pattern into the workload is likely the wrong key-management decision.

Make the escalation path explicit

A policy does not need to guess its way through an ambiguous request. When the commitment is missing, the scope is too broad, or tainted content affects the decision, stop and ask for review. That is the same operational move behind human approval gates for risky agent actions: preserve the exact action surface instead of approving a vague future intent.

The paper also notes a taint-laundering caveat. Its prototype does not expose a write_file tool, which closes one local-storage path; deployments that do permit writable scratchpads need a filesystem-level taint-propagation rule. That is a systems property to design and test, not a guarantee supplied by a prompt.

A practical checklist

• Keep the signing key outside ordinary host-readable storage.
• Bind every signing request to a session identity and narrow scope.
• Validate the commitment and relevant arguments before execution.
• Carry taint or provenance through any writable intermediate storage.
• Escalate missing, ambiguous, or high-impact commitments to a human.
• Test the boundary against the injection and misuse paths that match your tools.