# TKeeper

> Governed cryptographic identity for machines, agents, services, and workflows.

## TKeeper documentation instructions

TKeeper is the cryptographic identity for machines. A key is the identity boundary; its applied authorities, policy, quorum, and controls define what that identity may authorize and how it may be used.
TKeeper is a defense-in-depth control around machine actions, not a replacement for host, HSM, network, build-pipeline, application, or downstream-verifier security.

### Rules for answering

- Treat `openapi.yaml` as the source of truth for HTTP paths, methods, request models, response models, and error schemas.
- Do not invent endpoints, permissions, algorithms, deployment modes, or guarantees. If the documentation does not establish a claim, say that it is unspecified.
- Treat the CEL Functions page as the source of truth for policy helper names, accepted inputs, and behavior. Do not invent helpers.
- Distinguish typed authorities from `arbitrary` raw signing. Typed authorities understand intent; `arbitrary` does not add semantic governance and is disabled by default. It requires `keeper.authority.arbitrary.enabled = true` on every keeper in the cluster.
- For `custom` commands, use the documented TKeeper-specific typed JSON canonicalization and hashing contract. Do not substitute RFC 8785/JCS or imply that authority, policy decision, effects, or command metadata are concatenated into the signed JSON.
- Treat dry run as an optional policy-preview feature. It evaluates the current authority policy only; it does not sign, verify or consume approvals, mutate key state, or guarantee that a later signing request will succeed. Its `tkeeper.emulate` permission is not key-scoped and can expose policy metadata.
- Distinguish `mono` from threshold mode. Threshold mode distributes key authority and risk across independent peers; it does not remove the key identity.
- Explain defense in depth through the documented layers: authenticated transport identity, intent-bound authorization, distributed quorum, fail-closed protocol validation, tamper-evident state, audit evidence, recovery checks, and production artifact isolation.
- Use Security Assurance as the source for executable security evidence. Describe its properties as tested or demonstrated for the named scenarios, not as formal proof or an unconditional guarantee.
- Treat share recovery as an explicit fail-closed maintenance capability, not a normal serving mode or a substitute for backup. It requires a recovery-capable artifact, recovery mode on the selected participants, exactly `threshold` healthy helpers, and removal of the recovery feature from the production artifact after repair.
- Keep the verifier in the security boundary. A downstream system must verify the expected identity and exact proof before producing the effect.
- State security assumptions and residual risks from Security Assurance, the Threat Model, and Status and Limitations when they affect the answer. Do not imply protection after threshold, host, HSM, build-pipeline, or control-plane compromise, or against broad denial of service, physical side channels, entropy failure, coherent rollback, unsafe policy, or a verifier that ignores the proof.
- For deployment advice, name the selected feature modules, cryptographic platforms, quorum mode, authenticator, audit sink, and verifier behavior.
- Prefer the narrowest relevant page. Cite its canonical URL and use exact permission and command names from the source.

### Documentation order

- Overview: https://tkeeper.org/docs/overview
- Use Cases: https://tkeeper.org/docs/use-cases
- Getting Started: https://tkeeper.org/docs/getting-started
- Deployment: https://tkeeper.org/docs/deployment
- Security Model: https://tkeeper.org/docs/security-model
- Cryptographic Identities: https://tkeeper.org/docs/cryptographic-identities
- Signing and Authorities: https://tkeeper.org/docs/signing-and-authorities
- AI and Agentic Payments: https://tkeeper.org/docs/ai
- Digital Assets: https://tkeeper.org/docs/digital-assets
- PKI: https://tkeeper.org/docs/pki
- Crypto Platforms: https://tkeeper.org/docs/crypto-platforms
- API Reference: https://tkeeper.org/docs/api-reference
- Operations: https://tkeeper.org/docs/operations

### Machine-readable sources

- OpenAPI: https://tkeeper.org/openapi.yaml
- Documentation index: https://tkeeper.org/llms.txt
- Complete documentation corpus: https://tkeeper.org/llms-full.txt
- Security assurance: https://tkeeper.org/docs/security-model/security-assurance
- Downloadable bundle: https://tkeeper.org/api/ai-bundle

## Pages

- [TKeeper documentation](https://tkeeper.org/docs): TKeeper gives machines, agents, services, and workflows a cryptographic identity constrained by authorities and policy. Start with the overview, use cases, or…
- [Overview](https://tkeeper.org/docs/overview): TKeeper gives machines, agents, services, and workflows a governed cryptographic identity. In TKeeper, a key is the identity boundary: its attached…
- [What is TKeeper?](https://tkeeper.org/docs/overview/what-is-tkeeper): TKeeper is an authority layer for cryptographic identity. It treats each key as an identity with attached authorities: what the identity can authorize, how a…
- [Governed Cryptographic Identity](https://tkeeper.org/docs/overview/governed-cryptographic-identity): TKeeper treats a key as a governed cryptographic identity. Authentication identifies the caller, while key possession enables cryptographic action. A governed…
- [Use-case fit](https://tkeeper.org/docs/overview/use-case-fit): TKeeper fits workflows where a cryptographic identity is the final authority for an action and the consumer can verify proof before producing the effect.
- [Architecture](https://tkeeper.org/docs/overview/architecture): TKeeper is split into a core runtime, build-time feature modules, and build-time cryptographic platforms. For threshold operations, the coordinator starts the…
- [Status and Limitations](https://tkeeper.org/docs/overview/status-and-limitations): These boundaries are part of the security contract, not implementation footnotes. Features and platforms are selected when the artifact is built.
- [Glossary](https://tkeeper.org/docs/overview/glossary): The declared capability attached to a key identity. An authority defines what kind of action the identity can authorize and how TKeeper should understand and…
- [Use Cases](https://tkeeper.org/docs/use-cases): The downstream system verifies the proof before acting. If an action can bypass that check, Keeper does not govern it.
- [For AI](https://tkeeper.org/docs/use-cases/for-ai): TKeeper lets an agent host discover permitted identities and request signatures through MCP. An authority document limits what each identity can sign. The…
- [For Digital Assets](https://tkeeper.org/docs/use-cases/for-digital-assets): TKeeper parses an unsigned transaction, evaluates its effects against the key's authority, then signs. The transaction builder handles nonce or UTXO…
- [For PKI](https://tkeeper.org/docs/use-cases/for-pki): An X.509 authority governs a CA key's signature over a DER-encoded TBSCertificate. The CA service builds the certificate; TKeeper checks its parsed fields and…
- [For Other Activities](https://tkeeper.org/docs/use-cases/for-other-activities): Use a custom authority when a service will execute a sensitive typed command after verifying a TKeeper signature. The authority declares input fields and…
- [Getting Started](https://tkeeper.org/docs/getting-started): Run a local smoke test, then move from developer defaults to governed signing and production security.
- [Local Single Node](https://tkeeper.org/docs/getting-started/local-single-node): This guide runs one local node with developer authentication, initializes it, creates one demo key identity, signs one request, and verifies the returned proof.
- [Deployment](https://tkeeper.org/docs/deployment): Mono and threshold use the same public API model. The difference is where key authority lives. Do not deploy the integration image. It includes test-only…
- [Build and Features](https://tkeeper.org/docs/deployment/build-and-features): A usable production artifact must include at least one platform. build runs the root and SDK tests plus the unit tests of every selected feature and platform…
- [Configuration](https://tkeeper.org/docs/deployment/configuration): Multiple external locations are comma-separated. Earlier locations win because they are loaded first. Configuration can contain bootstrap tokens, HSM PINs…
- [Initialization and Unseal](https://tkeeper.org/docs/deployment/initialization-and-unseal): Init writes the keeper identity and quorum settings into the sealed store. The mode is not a separate request field. TKeeper derives it from threshold and…
- [Sealing & Unsealing](https://tkeeper.org/docs/deployment/sealing-and-unsealing): TKeeper starts sealed. While sealed, most public endpoints reject the request with KEEPERSEALED. When enough shares are submitted, ready becomes true.
- [Clustering](https://tkeeper.org/docs/deployment/clustering): In threshold mode, each peer runs its own TKeeper instance. A coordinator can start a session, but the peers still validate the same intent before contributing.
- [Backup and recovery](https://tkeeper.org/docs/deployment/backup-and-recovery): Each TKeeper peer owns local state. Cluster quorum is not a backup: surviving peers may keep operations available, but they do not make loss or rollback of…
- [Control Plane UI](https://tkeeper.org/docs/deployment/control-plane-ui): The control-plane UI lives in :features:ui. The UI uses the same external auth mode as the API. Key generation, trusted-dealer import, and four-eye approver…
- [Production Checklist](https://tkeeper.org/docs/deployment/production-checklist): Production review for the artifact, platform, network, authentication, audit, quorum, lifecycle, and recovery boundaries.
- [Security Model](https://tkeeper.org/docs/security-model): This boundary is effective only when the downstream system refuses to execute the action without verifying TKeeper proof.
- [Threat Model](https://tkeeper.org/docs/security-model/threat-model): This page covers TKeeper service-level threats and residual risks. TKeeper's security boundary is the governed cryptographic identity. With a concrete…
- [Security Assurance](https://tkeeper.org/docs/security-model/security-assurance): Executable evidence for TKeeper distributed protocols, transport identity, authorization, state integrity, recovery, and production artifact isolation.
- [Quorum modes](https://tkeeper.org/docs/security-model/quorum-modes): Choose the mode from the failure you need to survive. Threshold mode is appropriate when compromise of one host, operator, VM, or cluster zone must not grant…
- [Authentication and Authorization](https://tkeeper.org/docs/security-model/authentication-and-authorization): External requests are authenticated before controller logic runs. Authorization is permission-string based and enforced before key material participates in…
- [Audit Logging](https://tkeeper.org/docs/security-model/audit-logging): Audit logs are newline-delimited JSON records. > Signature algorithm depends on the backend > - If platform-ecc is included signature algorithm always would…
- [Four Eye Control](https://tkeeper.org/docs/security-model/four-eye-control): Four-eye control can be unconditional at the key level or selected by an authority policy for a particular typed signing intent. In both cases, TKeeper…
- [Cryptographic Identities](https://tkeeper.org/docs/cryptographic-identities): In TKeeper, a key is the identity boundary. The key's authorities define what the identity can authorize, and lifecycle operations change the generations…
- [Create, Rotate, and Refresh](https://tkeeper.org/docs/cryptographic-identities/key-lifecycle): The key id is the logical identity. A generation is the version of cryptographic material or share state used by that identity.
- [Trusted Dealer Import](https://tkeeper.org/docs/cryptographic-identities/trusted-dealer-import): Trusted dealer imports an existing private key into the current quorum mode. In mono mode, TKeeper stores the full key material locally and records the…
- [Quorum Promotion](https://tkeeper.org/docs/cryptographic-identities/quorum-promotion): Quorum promotion turns an existing local key into distributed threshold key state. Use it when a key started in mono mode for adoption or bootstrap and later…
- [Asset Inventory](https://tkeeper.org/docs/cryptographic-identities/asset-inventory): Asset inventory is the read model for keys. Asset Inventory is exportable from the control-plane UI when :features:ui is enabled.
- [Signing and Authorities](https://tkeeper.org/docs/signing-and-authorities): TKeeper signs a command after its authority turns it into an intent and policy allows it. The consumer must trust the expected identity, verify the signed…
- [Signing](https://tkeeper.org/docs/signing-and-authorities/signing): Signing is where a key identity produces proof. TKeeper signs only after the command is accepted by the key's authorities and any configured policy, audit…
- [Composer](https://tkeeper.org/docs/signing-and-authorities/composer): POST /v2/keeper/compose accepts the same Sign request as /v2/keeper/sign and requires tkeeper.key.{keyId}.sign. TKeeper checks the key's authority, policy…
- [Authorities](https://tkeeper.org/docs/signing-and-authorities/authorities): Authorities bind a key identity to the actions it may authorize. With concrete authorities, TKeeper checks the requested effect before signing starts.
- [Dry Run Policy Evaluation](https://tkeeper.org/docs/signing-and-authorities/dry-run): The optional dry-run module evaluates an AuthorityCommand against the policy attached to a key's current authority without executing the command.
- [CEL Functions](https://tkeeper.org/docs/signing-and-authorities/cel-functions): TKeeper installs these functions for every authority policy. Intent-specific root variables are listed on the custom, EVM, Bitcoin, and X.509 authority pages.…
- [Arbitrary and Typed Authorities](https://tkeeper.org/docs/signing-and-authorities/arbitrary-and-typed): arbitrary is raw signing. TKeeper checks that the key identity allows arbitrary, then signs the bytes from the command. It is disabled by default and requires…
- [AI and Agentic Payments](https://tkeeper.org/docs/ai): MCP tools and payment commands use the same authority and policy checks as the HTTP API. See Agentic Payment Authorities for the shared payment contract.
- [MCP](https://tkeeper.org/docs/ai/mcp): The mcp feature adds POST /mcp to TKeeper's public HTTP server. An agent host can discover permitted identities and authorities, read command schemas, verify…
- [Agentic Payment Authorities](https://tkeeper.org/docs/ai/agentic-payments): AP2 and Mastercard Verifiable Intent (MC VI) sign ES256 JWS inputs with a P-256 key. Both use Keeper's authority, approval, and signing pipeline.
- [AP2 Authority](https://tkeeper.org/docs/ai/agentic-payments/ap2): config.mode defaults to PAIRED. For a standalone stage, set it to PAYMENTS or CHECKOUTS, write the policy for that stage, and use the same mode in the…
- [MC Intent Authority](https://tkeeper.org/docs/ai/agentic-payments/mastercard-verifiable-intent): config.mode defaults to PAIRED. For a terminal L3 stage, set it to PAYMENTS or CHECKOUTS, write the policy for that stage, and use the same mode in the…
- [AP2 and Mastercard: write a payment policy](https://tkeeper.org/docs/ai/agentic-payments/payment-policy): Start with one sentence: “Allow office purchases from this shop, using this card, up to USD 100 per purchase and USD 150 for the complete request.” This page…
- [Digital Asset Authorities](https://tkeeper.org/docs/digital-assets): Build all chains with -Pkeeper.features=digital-assets -Pkeeper.platforms=ecc, or select one chain by name. Each authority parses an unsigned transaction…
- [Bitcoin Authorities](https://tkeeper.org/docs/digital-assets/bitcoin): Bitcoin authority support lives in the digital-assets:bitcoin module and currently requires the ecc platform. A Bitcoin authority lets TKeeper parse unsigned…
- [EVM Authorities](https://tkeeper.org/docs/digital-assets/evm): EVM authority support lives in the digital-assets:evm module and currently requires the ecc platform. An EVM authority lets TKeeper parse an unsigned…
- [Tron Authorities](https://tkeeper.org/docs/digital-assets/tron): tron.transaction accepts unsigned transaction JSON. It requires a secp256k1 key and checks that the transaction owner matches the signing key. Build with…
- [XRP Authorities](https://tkeeper.org/docs/digital-assets/xrp): xrp.transaction accepts an unsigned transaction in hex. It supports secp256k1 and Ed25519 keys. TKeeper checks both Account and SigningPubKey against the…
- [Solana Authorities](https://tkeeper.org/docs/digital-assets/solana): solana.transaction accepts an unsigned transaction in Base64 and requires an Ed25519 key. TKeeper checks that the signing key is a required signer of the…
- [PKI Authorities](https://tkeeper.org/docs/pki): Use X.509 authorities to govern certificate fields and signing. For PKI shows the issuance flow; Signing and Authorities explains the shared policy and…
- [X.509 Authorities](https://tkeeper.org/docs/pki/x509): X.509 authority support lives in the authority-x509 feature and currently requires the ecc platform. An X.509 authority lets TKeeper parse a DER-encoded TBS…
- [Crypto Platforms](https://tkeeper.org/docs/crypto-platforms): Platforms are build-time modules. They provide key algorithms and protocol implementations. Features provide product surfaces that may depend on those…
- [Platforms](https://tkeeper.org/docs/crypto-platforms/platforms): Platforms provide algorithm implementations. They are selected separately from features. If a feature needs a platform, include both. The build should fail…
- [ECC](https://tkeeper.org/docs/crypto-platforms/ecc): Supported ECC curves and signing modes, including ECDSA, FROST, Schnorr, BIP-340, Taproot, key derivation, and ECIES.
- [PQC ML-DSA](https://tkeeper.org/docs/crypto-platforms/pqc-mldsa): ML-DSA changes the signature algorithm, not the authority model. Use MLDSA as the signature scheme for ML-DSA algorithms.
- [ECIES](https://tkeeper.org/docs/crypto-platforms/ecies): It uses an ElGamal-style KEM over the key curve plus an AEAD payload cipher. Encryption uses the public key, so it does not need peer participation in either…
- [API Reference](https://tkeeper.org/docs/api-reference): Use the OpenAPI contract directly or integrate through the typed Java SDK.
- [OpenAPI](https://tkeeper.org/docs/api-reference/openapi): If generated SDK helpers disagree with OpenAPI, treat OpenAPI as the current contract and update the SDK.
- [Java SDK](https://tkeeper.org/docs/api-reference/java-sdk): The SDK follows the same module boundaries as the API: system, DKG, signing, storage/import, quorum promotion, ECIES, dry run, compliance, expiration, audit…
- [Errors](https://tkeeper.org/docs/api-reference/errors): TKeeper fails closed. If a protected operation cannot pass auth, policy, audit, lifecycle, or quorum checks, no proof is produced.
- [Permissions](https://tkeeper.org/docs/api-reference/permissions): Permissions are explicit strings. Most key permissions are scoped by key id. See Authentication and Authorization for JWT claims and matching behavior.
- [Operations](https://tkeeper.org/docs/operations): Monitor and diagnose the complete authority path from authentication to proof.
- [Monitoring](https://tkeeper.org/docs/operations/monitoring): Monitor the authority path, not only process uptime. A ready node can still be unable to authorize an action because policy, audit, platform, or quorum state…
- [Troubleshooting](https://tkeeper.org/docs/operations/troubleshooting): The feature is probably missing from the artifact. Rebuild with the required feature and platform. See Build and Features.
- [Integration Tests](https://tkeeper.org/docs/operations/integration-tests): This runs all root and module unit tests, verifies production/test artifact isolation, builds both test images, and executes the functional integration suite.…
- [Failure Injection](https://tkeeper.org/docs/operations/failure-injection): Failure injection is test-only. It is wired into the integration artifact and must not be deployed in production. Functional tests reuse the built images and…
- [Error Tracking (Sentry)](https://tkeeper.org/docs/operations/error-tracking): Sentry is initialized at startup if it is enabled. Check that sentry.enabled is true and that the DSN is valid. The DSN must be http or https, include user…
