Two-Key
Two independent keys must turn before an AI agent can act. No human needed.
AI agent authorization and MCP gateway with dual-path authorization. Deterministic bytecode policy combined with AI judge approval, single-use capability tokens, and an encrypted ledger.
🎯 The Problem
AI agents can be given permission to use a tool without being given
authority to perform every consequential action that tool can perform.
Traditional tool permissions answer:
"Can this agent call this tool?"
Two-Key asks a different question:
"Is this specific action authorized to execute?"
Two-Key is an authorization layer for AI agents that use tools. Before a consequential tool call executes, Two-Key requires independent authorization through a deterministic policy path and an independent judge path:
- The policy key (Path A). The rules you sign compile to bytecode. A
small deterministic VM checks every call against fields read from the
call's own arguments: the tool, the amount, the counterparty, the data
class, and fields you define. It reads no prose, so no prompt can talk it
out of a rule.
- The judgment key (Path B). One or more AI judges, each with its own
credential, review the call against your written constitution. Two-Key
refuses to start with a judge that holds the agent's own credential.
Only when both keys turn does Two-Key issue a single-use token, bound to the
exact arguments, the signed constitution, and the ledger state. The gateway
runs the tool only with that token, and every decision, allowed or denied,
is written to an encrypted, hash-chained ledger with a signed head.
What you get:
- Works with the agent you have. Grok, ChatGPT, Claude, Gemini, or a
local model (i.e. Ollama) proposes the call as data; Two-Key decides.
- Judges you choose. xAI, OpenAI, Anthropic, Gemini, or a local model. One
judge is enough to start; the
high_assurance profile asks for judges
from two makers and a yes from a local one.
- In front of any MCP server (0.5.0).
two-key mcp-proxy shows the
agent only the tools you signed and runs every call through both keys.
- Facts from your systems, not from the agent (0.5.0). A field such as
"this invoice matches its purchase order" comes from your own lookup,
and is looked up again just before the tool runs.
- An audit trail you can check. AES-256-GCM at rest, a hash chain, a
head signed by the principal and a witness key, and
two-key audit.
- A copy in your SIEM (0.7.0). Every decision can go to
syslog or an HTTPS webhook as it is written, in Two-Key's own schema, ECS,
or OCSF, with reason codes and digests but no argument values. A collector
that is down never blocks a decision.
- Keys you can recover. Passphrase backup of every key, in three
bundles.
- Small on purpose. Python 3.10 to 3.14, one required dependency
(
cryptography), Apache-2.0.
Status: beta. 0.9.1 is the current release: ledger rollover into
encrypted archives, a TypeScript tool-check helper, and fixes from the 0.9.0
review. 0.9.0, the last beta before 1.0, made every signature is hybrid Ed25519 + ML-DSA-65 (quantum-resistant), a 0.8.0
deployment's keys are upgraded once at the first start, a tool behind the
proxy can check its own calls (the tool check), a tool error spends its
token, and two-key setup --window sets up in a window. 0.8.0 added a
summary of recent decisions for the judges, each judge's ballot in the
ledger, one proxy per agent, a read-only ledger audit window
(two-key ledger-view) and a constitution editor. 0.7.3 added two-key setup and
two-key config set, get, undo and check for setting up and changing a
deployment, a signed serial so a ledger never goes back to older rules, and
start-up checks for the upstream server's files behind a launcher. 0.7.0
added the SIEM export, a start-up check that refuses to run when the
monitored agent is Two-Key's own account, and a count of the tokens the
gateway refuses.
Maintainer-reviewed and tested with live LLM agents and judges. Read
Known limits and docs/FIT.md before you rely
on it.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
