Cryptographic Security

human.tech is built so that security holds by construction, not by trusting a single server or operator. A few primitives do the heavy lifting.

Two-Party Computation (2PC)

In Wallet-as-a-Protocol (WaaP), a signing key is never assembled in one place. It is split into two shares: a Sovereign Share controlled by the user’s device and derived from their credentials, and a Security Share held in a secure enclave. Signing requires both shares to cooperate, and neither is ever combined into a full key.

The result is that there is no single point of compromise. If a device is compromised, the attacker still cannot sign without the enclave share. If the server side is compromised, the attacker gets only an encrypted share they cannot use without the user’s credentials.

Policy Engine

Before any transaction is signed, WaaP’s policy engine evaluates it against rules the account owner sets. It enforces spend limits, requires step-up approval for higher-risk actions, and simulates each transaction to catch malicious payloads (protection against blind signing).

For automated callers, scoped permissions (Privileges) let an owner pre-approve a narrow set of actions, such as a specific recipient, amount cap, chain, and expiry. An AI agent can act smoothly within those bounds while anything outside them is gated back to a human.

Threshold cryptography

Where identity data must be protected, it is encrypted to a threshold network (Human Network) rather than to any single server. Operations are split across many nodes so that a quorum is required to act, and no single node can read the data or reconstruct a key on its own. The same approach generates keys from user-side authentication without any one party ever holding the result.

Zero-knowledge proofs

Identity claims are proven without revealing the data behind them, so no personal information is written on-chain in the clear. See Zero-Knowledge Identity and Proof of Clean Hands.

Credential handling for agents

When an AI agent needs to call an external service, it should never hold raw API keys or secrets. human.tech routes those calls through a credential proxy (TAP) that injects the right credential at request time, so secrets are not exposed in agent logs, prompts, or process arguments. Combined with the policy engine, this keeps an agent’s authority scoped and its secrets out of reach.

Audited

These systems are independently audited. See Security & Audits.