# 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…
