# 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. - 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. - 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 - 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 whose use is constrained by explicit authorities and policy. - [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): If the action can happen without the proof, TKeeper is not enforcing that path. If the goal is only secret storage, use a secrets manager. - [For AI Agents](https://tkeeper.org/docs/use-cases/ai-agents): Use TKeeper when an AI agent or autonomous workflow can request actions with real consequences and the executing backend can require cryptographic… - [For Crypto Assets](https://tkeeper.org/docs/use-cases/crypto-assets): Use TKeeper when transaction signing must depend on an understood transaction, policy, and optionally external risk or human verdicts. - [For Certificates](https://tkeeper.org/docs/use-cases/certificates): Use TKeeper when use of a CA key must depend on an understood TBS certificate and explicit issuance policy. The boundary is the CA key identity. If issuing a… - [For Internal Systems](https://tkeeper.org/docs/use-cases/internal-systems): Use TKeeper when an internal system should execute a sensitive action only after verifying authorization by a specific machine or workflow identity. - [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): Signing is an identity action. TKeeper produces a signature only after the requested action is understood through an authority and allowed by policy. - [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… - [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. - [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. Do not use it when TKeeper is expected… - [EVM Authorities](https://tkeeper.org/docs/signing-and-authorities/evm): EVM authority support lives in the authority-evm feature and currently requires the ecc platform. An EVM authority lets TKeeper parse an unsigned serialized… - [Bitcoin Authorities](https://tkeeper.org/docs/signing-and-authorities/bitcoin): Bitcoin authority support lives in the authority-bitcoin feature and currently requires the ecc platform. A Bitcoin authority lets TKeeper parse unsigned… - [X.509 Authorities](https://tkeeper.org/docs/signing-and-authorities/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, 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…