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

### 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.
- 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.
- 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 the Threat Model and Status and Limitations pages when they affect the answer.
- 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
- 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 authorities define what the identity is allowed to authorize.
- [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 request is understood, which policy governs it, and what proof another system should verify before execution.
- [Governed Cryptographic Identity](https://tkeeper.org/docs/overview/governed-cryptographic-identity): TKeeper treats a key as a governed cryptographic identity.
- [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.
- [Status and Limitations](https://tkeeper.org/docs/overview/status-and-limitations): These boundaries are part of the security contract, not implementation footnotes.
- [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 govern requests for that action.
- [Use Cases](https://tkeeper.org/docs/use-cases): Every supported use case has the same enforcement shape:
- [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 authorization.
- [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.
- [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): Deployment has three decisions:
- [Build and Features](https://tkeeper.org/docs/deployment/build-and-features): TKeeper has two build-time selectors:
- [Configuration](https://tkeeper.org/docs/deployment/configuration): TKeeper reads config in this order:
- [Initialization and Unseal](https://tkeeper.org/docs/deployment/initialization-and-unseal): Init writes the keeper identity and quorum settings into the sealed store.
- [Sealing & Unsealing](https://tkeeper.org/docs/deployment/sealing-and-unsealing): TKeeper starts sealed. While sealed, most public endpoints reject the request with `KEEPER_SEALED`.
- [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 one peer's database harmless.
- [Control Plane UI](https://tkeeper.org/docs/deployment/control-plane-ui): The control-plane UI lives in `:features:ui`.
- [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): For typed authorities, TKeeper enforces a cryptographic authority boundary:
- [Threat Model](https://tkeeper.org/docs/security-model/threat-model): This page covers TKeeper service-level threats and residual risks.
- [Quorum modes](https://tkeeper.org/docs/security-model/quorum-modes): TKeeper supports two custody modes:
- [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 the operation.
- [Audit Logging](https://tkeeper.org/docs/security-model/audit-logging): Audit logs are newline-delimited JSON records.
- [Four Eye Control](https://tkeeper.org/docs/security-model/four-eye-control): Four-eye control is a key policy. It requires `m` distinct approver signatures from `n` configured approver keys before TKeeper continues.
- [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 through which that identity operates.
- [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.
- [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 needs quorum protection.
- [Asset Inventory](https://tkeeper.org/docs/cryptographic-identities/asset-inventory): Asset inventory is the read model for keys.
- [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, lifecycle, and quorum controls.
- [Authorities](https://tkeeper.org/docs/signing-and-authorities/authorities): Authorities bind a key identity to the actions it may authorize.
- [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.
- [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.
- [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.
- [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.
- [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.
- [Platforms](https://tkeeper.org/docs/crypto-platforms/platforms): Platforms provide algorithm implementations. They are selected separately from features.
- [ECC](https://tkeeper.org/docs/crypto-platforms/ecc): The `ecc` platform provides:
- [PQC ML-DSA](https://tkeeper.org/docs/crypto-platforms/pqc-mldsa): The `pqc` platform provides:
- [ECIES](https://tkeeper.org/docs/crypto-platforms/ecies): ECIES lives in `:features:ecies`.
- [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): The OpenAPI file is the source of truth:
- [Java SDK](https://tkeeper.org/docs/api-reference/java-sdk): The Java SDK provides typed modules for the public TKeeper API:
- [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.
- [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 is failing.
- [Troubleshooting](https://tkeeper.org/docs/operations/troubleshooting): Most failures map to one authority-path stage:
- [Integration Tests](https://tkeeper.org/docs/operations/integration-tests): The integration image is built with:
- [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.
- [Error Tracking (Sentry)](https://tkeeper.org/docs/operations/error-tracking): Sentry is initialized at startup if it is enabled.