Algorand Foundation launches AC2 for hardware-backed agent approvals

Algorand Foundation has put a protocol around a failure mode agent teams already live with: a chat-thread “yes” is not proof of intent, and an API key injected into a runtime is not isolation.

On August 25, 2026, the Foundation published AC2 — Agentic Communication & Control Protocol — as an open, blockchain-agnostic standard for peer-to-peer communication between users and AI agents. A same-day PR Newswire release from Dover, Del., carries the public launch. The pitch is specific. Users keep signing keys on their own hardware. Agents get a signed authorization, not the credential itself.

That is not a claim that credential fencing is new. Scoped accounts, least-privilege tokens, and human-in-the-loop gates already exist. AC2’s bet is cryptographic and placement-focused: approvals are FIDO2/WebAuthn signatures over DIDComm messages, sent on a WebRTC data channel, with keys remaining on the user’s device.

Proof of intent, not a thread reply

The Foundation’s launch post starts from a familiar story. An agent that reviews pull requests, preps merges, and runs tests is useful until the runtime is compromised — in their example, by a malicious plugin dependency. Session tokens for the approval flow and API keys injected at startup go with it. A merge can look as if a lead engineer signed off, because the “approval” was a message in a chat thread.

AC2 is aimed at two gaps the Foundation says most agent systems still have:

There is no cryptographic proof a human authorized a specific action.
The agent holds credentials that should never have been in the runtime.

Instead of a spoofable chat confirmation, the agent sends a request, the user reviews it on their device, and approval is a FIDO2 passkey signature — hardware-bound, and described as phishing- and forgery-resistant. The intended artifact is a verifiable audit trail: who approved what, and when.

Chat-based confirmations in WhatsApp, Telegram, or Slack, the Foundation argues, rest on session tokens. A button tap is spoofable and invisible outside the conversation. Prompt injection can push agents toward self-approval. A simple chat “yes” does not prove who sent it, when, or what they were approving. AC2 does not claim to solve prompt injection. It changes the approval from a message into a hardware-backed signature.

Keys stay on the device

The second half of the design is where credentials live. Rather than injecting API keys into the agent and then hardening the box, AC2 keeps them on the user’s device to begin with. The agent receives signed authorization. If the runtime is compromised, there are no API keys sitting there to steal — at least not the ones this path was meant to keep out of that process.

In practice, AC2 sets up a direct, end-to-end encrypted WebRTC connection between a user’s wallet or app and an AI agent. When the agent needs a signing operation — a payment, a git commit, an API authorization — it sends a request over AC2. The user reviews and approves in their own wallet interface. The signature is delegated back. The private key never leaves the user’s control.

Three open standards carry the protocol:

DIDComm v2.0 for message formatting, so any framework that can construct a DIDComm message can speak AC2
WebAuthn/FIDO2 for authentication, with signatures bound to physical hardware such as a TPM or Secure Enclave rather than app-level tokens
WebRTC DataChannel for transport, peer-to-peer after the initial handshake, with no relay servers in the described design

The Foundation calls the basic flow lightweight — about fifty lines — and says it needs no containers, messaging SDK, or credential proxy. It is meant to sit beside an existing agent stack, upgrading the trust level rather than the workflow. The wire release adds that AC2 requires no central message relay and no blockchain to operate, even though Algorand Foundation is the publisher. Integration is described as one plugin and one command for a basic approval flow.

Passkey authentication is via Liquid Auth, built on FIDO2/WebAuthn. The Foundation points to prior work on Pera Wallet, Rocca, Intermezzo, and LiquidAuth as the authentication and P2P stack AC2 wraps for agents.

Marc Vanlerberghe, Chief Strategy and Marketing Officer at the Algorand Foundation, framed the product question this way: “AC2 is Algorand's answer to a fundamental question the industry has been sidestepping: how do you give AI agents the authority they need to be useful, without the authority to act against your interests? The answer is you don't hand them the keys, you approve each use of them.”

Commits, APIs, payments, then bounds

Listed workflows are concrete:

Code deploys. An agent prepares a commit or deploy and requests a signature before pushing. The signature is meant to prove exactly what was reviewed and approved.
Client communications. An agent drafts content and requests sign-off before sending.
API access. Request parameters are presented for approval before execution. The signature is meant to prove what was authorized, by whom, and when.
x402 payments. Payment details go to the user’s wallet for approval before the API call completes, without exposing private keys.
Intent-based actions. An agent can submit an AP2 IntentMandate defining what it may do and under what constraints. Once signed, it can act inside those limits.

The PR adds a shopping-agent example: construct an AP2 Intent Mandate — what to buy, at what price — submit it for sign-off, then act. Because AC2 supports extensions, the Foundation says any message type or signing format can be added. The protocol also supports real-time voice and text streaming as well as signing delegation.

Today’s default is still prompt-for-every-signature. The next iteration the Foundation describes is bounded delegation: define bounds once; inside them the agent acts; outside them it comes back. The security model they describe does not change — the agent still never gets the keys — only how often the user is asked.

Reference pieces, not a new Mac agent

This is a protocol launch with reference code, not an OpenClaw Mac product announcement. The spec and reference implementation are at github.com/algorandfoundation/ac2. The Foundation is also releasing an AC2 wallet app — the blog lists GitHub plus Play Store and App Store listings; the wire points to an open-source wallet proof-of-concept — and an npm package, @algorandfoundation/ac2-open-claw-reference, as an OpenClaw plugin so developers can walk an end-to-end approval flow. Design partners are invited to review the spec. The Foundation also points to ac2protocol.org, and says any agent platform or identity wallet should be able to speak AC2 without custom plugins, exposed credentials, or proprietary approval flows.

If you already isolate agent credentials with scoped accounts or short-lived tokens, treat AC2 as another boundary in that family: a passkey-signed, wallet-held path for commits, payments, and API auth, instead of env-injected secrets and a chat “yes.” The practical test is whether FIDO2 signatures over DIDComm on WebRTC are light enough to drop into an existing agent SDK without becoming the workflow.

Next step: Read the Foundation’s AC2 launch post, then clone the public spec and run the OpenClaw reference plugin through one commit-sign or API-auth flow so you can compare a passkey-backed approval to the chat or env-key path you use today.