Early Access

Audit & assurance for AI agents.

Every meaningful agent action ships with a signed receipt that commits to a hash of the result, names the issuing service's DID, and verifies offline against its public key. MCP, A2A, and AP2 defer the audit layer to “a future layer.” This is that layer.

Open protocol underneath. Hosted Registry and enterprise Console on top. Same shape as Stripe on payment rails or Auth0 on OAuth.

Wraps MCP / A2A / OAuth 2.1 / AP2 — doesn't replace them
MIT-licensed Python SDK and CC BY 4.0 spec on GitHub
Hosted Registry + Console, or self-hosted SKU for sovereign deployments
The problem

Security review is killing your agent pilot.

Your CISO is asking three questions. Today you can't answer any of them with evidence. Until you can, the pilot doesn't ship, and every Fortune 500 has the same conversation.

01

Agent identity is unverifiable.

When an agent calls an API, MCP server, or another agent, the receiving side has no cryptographic way to know who deployed it, what model is behind it, or whether its instructions were tampered with mid-flight.

"API keys identify the integration, not the invocation. A prompt-injected agent looks identical to a legitimate one."
02

Authority can't be delegated safely.

A user authorizes Agent A. A spawns sub-agent B. B calls Tool C, which calls Service D. By the time D is asked to act, there is no verifiable chain proving the user actually consented to D being called for this purpose, with these constraints, by this specific instance of B, on behalf of this specific session of A. The information existed at every hop. None of it survived.

"Enterprise agent rollouts are stalling at procurement and security review. This is why."
03

No signed audit trail.

Logs aren't proof.

"When something goes wrong, or right, there's no tamper-evident record of who authorized what and what actually happened. A liability nightmare for agent vendors. A blocker for regulated industries."
The protocol

Four primitives. One handshake.

Before two agents (or an agent and a service) do meaningful work together, they perform a handshake. Each side proves who they are, what they're authorized to do, and on whose behalf. Every action that follows is sealed with a signed receipt.

01, IDENTITY

Cryptographic agent identity

Every agent has a keypair and a verifiable credential bound to its deployer, model, version, and instance. Lightweight DID-compatible identifiers (did:hsk:agent:…) mean any party can verify any agent without phoning home.

02, DELEGATION

Provable chain of consent

User → agent → sub-agent → tool. Each step carries a signed delegation token narrowing scope and constraints. The receiving side can verify the entire chain back to a human principal, without trusting any intermediate.

03, CAPABILITY

Negotiated, scoped capabilities

A handshake is a typed negotiation, not a blank check. Capabilities are namespaced (billing.invoices.read), bound by constraints (max records, date range, TTL), and refused by default if not explicitly granted upstream. Refusals are themselves signed, so a denial is provable.

04, RECEIPT

Signed action attestations

Every meaningful action produces a signed receipt: what was promised, what was done, by whom, with a hash of the result. Receipts chain. Audit becomes a math problem.

How it works

One library call. Every action provable.

Handshake is designed to be invisible to the agent author. The SDK wraps your existing agent framework, adds the handshake to outbound calls, and produces signed receipts as a side effect of normal operation.

1

User authorizes the agent

The user signs a delegation token specifying scope, constraints, and TTL. This is the root of trust. Every downstream action traces back to it.

2

Agent initiates a handshake

Before calling a service, the agent sends a signed handshake message: its identity, the requested capability, the delegation chain, and the constraints it's operating under.

3

Service verifies and accepts

The service verifies signatures, walks the delegation chain, and confirms the requested capability is in scope. Either it accepts, or it refuses. No accept, no action. Refusals are signed too.

4

Action executes, receipt is sealed

The service runs the action, hashes the result, and returns a signed receipt. The receipt persists to the agent, the deployer, and (optionally) a tamper-evident registry.

handshake_message.jsonJSON
{
  "handshake": {
    "version": "0.2.3",
    "from": {
      "agent_id": "did:hsk:agent:0xa1b2c3…",
      "deployer": "acme.com",
      "model": "claude-sonnet-5",
      "instance_id": "session-7f3a"
    },
    "to": {
      "service_id": "did:hsk:svc:0xd4e5f6…",
      "capability": "billing.invoices.read"
    },
    "scope": {
      "capabilities": ["billing.invoices.read"],
      "constraints": {
        "max_invoices": 100,
        "date_range": ["2026-01-01", "2026-04-29"]
      },
      "ttl_seconds": 600
    },
    "delegation_chain": [
      {
        "principal": "did:hsk:user:bob@acme.com",
        "authorized": ["billing.invoices.read"],
        "signed_at": "2026-04-29T14:02:11Z",
        "signature": "0x…"
      },
      {
        "principal": "did:hsk:agent:0xa1b2c3…",
        "authorized": ["billing.invoices.read"],
        "signed_at": "2026-04-29T14:14:32Z",
        "signature": "0x…"
      }
    ],
    "signature": "0x…"
  }
}
verify.tsTYPESCRIPT
import { verifyReceipt } from "@handshake-ai/handshake/browser";

// Pass any handshake envelope or receipt; the verifier is fail-closed.
const result = await verifyReceipt(envelope, {
  registryBaseUrl: "https://registry.handshake.ai",
});

if (result.ok) {
  // Signature, delegation chain, and constraints all verified.
} else {
  console.error("verification failed:", result.reason);
}
Composition, not competition

Designed to fit the protocols you already use.

We wrap an attestation envelope around the protocols defining how agents talk to tools and to each other. Nothing gets replaced. The existing stack stays exactly where it is, and the things it already does well keep working. We add the audit layer those specs explicitly punted on.

MCP

Wraps MCP tool calls in a verifiable handshake; signed receipts cover every tool invocation.

A2A

Provides the identity and delegation primitives A2A's spec defers to "an external trust layer."

OAuth 2.1

Uses OAuth flows to bootstrap user delegation; carries the authority forward into agent-to-agent calls.

AP2 / payments

Plugs in as the attestation layer for AP2's mandate model. Provable receipts for every payment action.

Why now

Open-protocol audit and assurance for AI agents. Cross-vendor by design.

Four things converged inside eighteen months. The audit-and-assurance gap is the one piece nobody else is shipping a protocol for.

2025

MCP went mainstream

Anthropic, OpenAI, and Google all shipped agent capabilities. Tool ecosystems exploded, and so did supply-chain incidents.

Late 2025

A2A & AP2 launched

Google shipped Agent2Agent. Visa and Mastercard launched AP2 for agent payments. Both explicitly defer trust and identity to "a future layer."

Q1 2026

Enterprise pilots stalled

Security and procurement reviews started killing agent rollouts. The blocker is consistent: "we can't audit what the agent did, on whose authority."

2026 →

Regulation arrives

EU AI Act accountability provisions take effect. SOC2 and ISO scoping for agentic systems becomes a board-level question.

Roadmap

Open spec first. Hosted infra second.

The protocol ships in the open with a small group of design partners. Hosted infrastructure follows.

Status
Milestone
Current

v0.2.3 spec, Early Access. v0.1 → v0.2.0 → v0.2.3 shipped iteratively (see /spec change log). Working with first design partners.

Preview

SDK preview. Python and TypeScript SDKs ship in early access. Reference implementations for Anthropic SDK, OpenAI Agents SDK, LangGraph.

Planned

Production Registry beta. Hosted discovery and revocation directory. Optional, like CT logs for TLS.

Planned

Console GA. Policy management, audit reporting, compliance evidence export for security teams.

Research

v1.0 spec → standards body. RFC submission via IETF. Multi-vendor implementations and interoperability testing.

Design partner cohort

Get on a call with the people building this.

We work directly with security and platform teams shipping agents into production. Spec input, white-glove integration help, and a direct line to engineering.