TKeeper

TKeeper is an open-source, self-hosted authority layer that gives machines a cryptographic identity whose use is constrained by explicit policy. The problem it targets is that AI agents, services, and automated workflows increasingly hold keys that can sign transactions, issue certificates, or run privileged commands, and a single compromised process or a single stolen key is enough to lose everything. TKeeper sits between a proposed action and its backend effect, binding every machine action to intent, policy, quorum, and proof before it executes.

The core move is that no single point holds full signing power. In threshold mode, TKeeper spreads a signing identity across t-of-n peers using multi-party computation, so producing a signature requires a quorum of independent nodes to cooperate. Compromise one peer and you still can't sign. The threshold layer is built to tolerate Byzantine behavior, peers that fail, withhold messages, or send invalid cryptographic contributions, and key refresh lets a set of threshold peers replace compromised shares while preserving the public key, so rotation doesn't break everything downstream. For simpler deployments there's also a single-node mono mode, which makes a local single-node setup the natural entry point before scaling out.

Policy is where the governance happens. Agent requests are converted into typed intents that get evaluated against explicit authorities and policy before anything is signed. That structure is also TKeeper's answer to prompt injection, an agent that's been talked into doing something malicious still can't exceed its typed intent, its least-privilege scope, and the approvals its policy demands. Optional four-eye control requires multiple independent human approvers to review and sign the exact action an agent proposed, and everything that happens lands in a verifiable audit log, so you get proof of what was authorized and what actually ran.

The integration surface is broad for a young project. On the signing side it supports EVM chains, Bitcoin, X.509 certificate operations, and arbitrary custom signing, which covers crypto operations, PKI, and infrastructure automation with one system. Cryptographically it spans classical elliptic-curve schemes, ECIES for encryption, and post-quantum ML-DSA, so identities can be stood up on post-quantum signatures where that matters. Developers get an OpenAPI-documented HTTP interface and a Java SDK, and operators get an optional control plane UI for governance operations plus the usual key lifecycle, creation, rotation, refresh, and recovery.

The intended audience is teams whose machines already hold dangerous capabilities. That means platform and security engineers securing AI agent tool calls, crypto teams that want treasury or protocol keys behind a quorum, operators of certificate authorities and PKI, and anyone whose automation can touch critical infrastructure. If you've been uncomfortable handing an autonomous agent a raw private key or an all-powerful API token, this is the class of problem TKeeper exists for. The project also maintains a fundamentals library on the site that walks through the underlying ideas, agent identity, intent-based authorization, signing without key exposure, and Byzantine fault tolerance, which is worth reading even if you never deploy the software, because it lays out a coherent model for what machine identity should mean once agents act on your behalf.

What makes it different from a standard secrets manager or KMS is the combination of distributed authority and intent-level governance. A vault stores a key and hands it to whoever authenticates. TKeeper never exposes the key at all, agents request signatures through a governed identity, the request is checked as a typed intent against policy, a quorum produces the signature, and the audit trail proves the whole chain. It's closer to a programmable, self-hosted HSM with built-in approval workflows than to a password store, and the same identity model stretches across payments, deployments, and certificates instead of needing a separate control system for each.

Access is fully open source. You self-host it, single node to start, threshold peers when you need distributed trust, and there's no pricing page because there's nothing to buy. The code lives on GitHub under tkeeper-org, docs cover deployment, configuration, initialization, and unseal, and the team is reachable at labs@tkeeper.org. For a security tool, being able to read every line before you trust it with your keys is exactly the right posture.