Website · Documentation · OpenAPI · Java SDK
TKeeper manages cryptographic identities for AI agents, services, and other autonomous systems. Each cryptographic identity has:
- a key held by one node or split across peers;
- attached authorities that define accepted commands and policy;
- caller permissions, approval requirements, audit records, and key lifecycle controls.
- Require AI agents, services, and other non-human identities (NHIs) to obtain a signature for actions governed by key policy. The receiving system verifies the expected key and signed action before execution.
- Distribute key custody and request validation across a configurable quorum. Fewer than
tcompromised peers cannot sign alone, and an available quorum can continue operating. See Quorum Modes for assumptions and limits. - Sign digital asset transactions, payment mandates, certificates, and application commands under policies attached to their keys.
- Record policy decisions, approvals, and operation outcomes in signed audit events. Track key ownership, generations, and destruction state for operational and compliance reviews.
- A caller authenticates and requests a signature with a specific key.
- TKeeper checks permissions, validates the command against an attached authority, and evaluates its policy.
- The request must satisfy the key's controls, including any required approvals. In threshold mode, enough peers must accept the request and contribute to the signature.
- The receiving system verifies the expected key, signature, and signed action, checks freshness and replay rules, then executes the action (for example, broadcasting the transaction). See the verifier contract.
POST /v2/keeper/sign returns a signature.
POST /v2/keeper/compose runs the same checks and returns a signed transaction or payment credential for supported command types. Other types return the raw signature. See Signing and Authorities for requests and policy.
Raw arbitrary signing has no intent policy and is disabled by default.
| Work | Guide |
|---|---|
| Agent tools over MCP; AP2 and Mastercard Verifiable Intent payments | MCP action · AP2 · MC Intent |
| Bitcoin, EVM, Tron, XRP, and Solana transactions | For Digital Assets · Chain authorities |
| X.509 certificate signing | For PKI · X.509 example |
| Typed commands for internal systems | For Other Activities · Custom authorities |
TKeeper supports mono and threshold operating modes. In mono, one host holds the full key material; compromising that host compromises the identity.
In threshold mode, TKeeper uses multi-party computation (MPC) to sign with distributed key shares. Each peer holds one share and checks the request before contributing. A signature needs t accepted contributions from n peers. Normal threshold signing does not reconstruct the private key.
For a 2-of-3 identity, one compromised peer cannot sign alone or recover the key from its share. One unavailable peer leaves two that can still sign. The protection boundary ends at two compromised peers, and signing stops if fewer than two healthy peers can participate.
Place peers across separate hosts and failure domains to distribute compromise risk. Honest peers with matching authority and policy state reject actions that violate those rules, even if a minority peer is compromised. Keys created with distributed key generation never exist whole on one peer; imported or promoted keys may have existed whole earlier. See Quorum Modes and the Threat Model.
Follow Local Single Node to try TKeeper. A default production build requires Java 25:
./gradlew :build -Pkeeper.features=all -Pkeeper.platforms=allall includes default production features. Mandates, MCP, developer authentication, policy dry run, and recovery require explicit selectors. See Build and Features to select features, cryptographic platforms, and an OS/CPU target.
Use the Java SDK or OpenAPI to integrate. For production boundaries, read the Threat Model and Status and Limitations.
The functional suite tests protocol attacks, state corruption, and normal operations on multi-node deployments. Security Assurance links the scenarios and their limits. Run the release checks with ./gradlew releaseGate; Integration Tests lists the requirements and commands.
Apache License 2.0. See LICENSE.md.