Back to blog

Why AI Agents Need Cryptographic Human Approval

Alex Floyd||8 min read

In January 2025, a customer-support AI at a mid-size fintech firm autonomously issued $43,000 in refunds over a weekend. The agent had been given tool access to the refund API, a well-meaning system prompt to “prioritize customer satisfaction,” and no meaningful approval gate. By Monday morning, the damage was done.

This isn’t a hypothetical. As AI agents gain real autonomy — executing code, moving money, modifying infrastructure, signing contracts — the question is no longer “can we build agents that do things?” It’s “can we prove a human actually authorized the things they did?”

The autonomy problem

Modern agent frameworks — LangChain, CrewAI, OpenAI’s Assistants API, Anthropic’s tool use — make it trivially easy to give an AI the ability to call external APIs, run shell commands, and interact with databases. The agent decides which tools to call and in what order. You provide the tools; the model provides the judgment.

For low-stakes actions (searching a knowledge base, formatting a report), this works well. But for high-stakes actions (deploying to production, transferring funds, deleting data), the model’s judgment alone isn’t enough. You need a human in the loop. And not just anyhuman-in-the-loop mechanism — you need one that provides actual proof.

What’s wrong with current HITL solutions

Let’s look at what teams actually use today for human-in-the-loop approval:

Slack-based approvals

Services like HumanLayer send a Slack message with approve/reject buttons. The problem? Anyone in the channel can click the button. There’s no identity verification — no proof that the person who clicked is authorized, or even that they read what they were approving. A bot could click it. An intern could click it. There’s no cryptographic evidence of who approved what.

Email confirmation links

“Click this link to approve.” Links can be forwarded, phished, or clicked without reading. There’s no authentication at the point of approval. The link itself is the credential, and links are trivially shareable.

Custom webhook callbacks

Some teams build their own approval UIs with webhooks. Better than Slack buttons, but the approval is typically just a boolean flag in a database. If someone compromises the database or the webhook endpoint, they can forge approvals retroactively. There’s no independent, verifiable proof.

All of these approaches share the same fundamental flaw: the approval is just a state change in a mutable system.Flip a bit in a database, fire a webhook, click a button — none of these produce evidence that withstands scrutiny. If your compliance team, your auditor, or a court asks “prove this specific human approved this specific action at this specific time,” you have nothing.

What cryptographic proof actually means

A cryptographic approval is fundamentally different. When a human approves an action through SignedApproval, the system produces an Ed25519 digital signature over a canonical payload that includes the action description, the approver’s identity, the timestamp, and a nonce. This signature has three properties that matter:

1. Unforgeable

Only the holder of the private key can produce a valid signature. The private key never leaves the server — it’s encrypted at rest with AES-256-GCM. No amount of database access lets an attacker forge a signature without the encryption key.

2. Offline-verifiable

Anyone with the public key can verify the signature without contacting SignedApproval. The verification is a pure mathematical operation. Even if our servers go down, the proof remains valid.

3. Tamper-evident

The signature covers the exact action text, timestamp, and approver identity. Change a single character in the action description, and the signature becomes invalid. There’s no way to retroactively alter what was approved.

The authentication gap

Cryptographic signing is necessary but not sufficient. You also need to prove that the person who triggered the signature was actually the authorized human — not someone who stole their session, guessed their password, or intercepted a link.

This is why SignedApproval requires strong authentication at the moment of approval. The approver must authenticate with one of three methods, each of which binds the approval to a specific human identity:

  • Passkey (FIDO2/WebAuthn)— hardware-bound credential that requires physical presence and biometric or PIN
  • TOTP authenticator— time-based one-time password from a device the user physically possesses
  • Face ID via iOS app— biometric authentication tied to the device’s Secure Enclave

The authentication method is recorded in the signed payload. When you verify an approval, you know not just that it was approved, but howthe approver authenticated. A passkey-authenticated approval carries different weight than a TOTP approval — and your policies can enforce which methods are acceptable for which actions.

Where this matters most

Cryptographic human approval isn’t needed for every agent action. It’s needed where the cost of an unauthorized action is high:

DomainActions requiring approval
FinancialTransfers, refunds, invoice payments above threshold
InfrastructureProduction deployments, database migrations, config changes
DataBulk deletes, PII exports, schema changes
LegalContract signing, compliance submissions, regulatory filings
SecurityKey rotation, permission grants, firewall rule changes

The regulatory landscape is catching up

The EU AI Act, NIST’s AI Risk Management Framework, and SOC 2 auditors are all converging on the same requirement: if an AI system takes consequential actions, there must be documented human oversight. “We sent a Slack message” doesn’t satisfy this. A cryptographically signed, timestamped, identity-bound approval record does.

Organizations that build cryptographic approval into their agent workflows today won’t have to retrofit it when regulators come knocking. The audit trail is already there — immutable, verifiable, and tied to specific human identities.

Getting started

SignedApproval is designed to slot into any agent framework with a single API call. The agent POSTs an action description, the human authenticates on their phone, and the agent gets back a signed credential it can verify independently. No webhooks required, no polling infrastructure, no Slack workspace to manage.

const result = await sa.requestApproval({
  action: "Deploy v2.4.1 to production",
  ttl: 300,
});

if (result.decision === "approved") {
  // result.signature is a valid Ed25519 signature
  // result.publicKey lets you verify offline, forever
  await deploy("v2.4.1", "production");
}

Read our integration guide for framework-specific examples, or get an API key and try it in five minutes. The free tier includes 200 approvals per month — enough to instrument your most critical agent workflows today.

AI SafetyHITLThought Leadership

Related posts

Ready to add cryptographic approvals to your agents?

200 free approvals per month. No credit card required.

Get your API key