Algorand Foundation Launches AC2: The Protocol That Keeps AI Agents Away From Your Private Keys

The Problem AC2 Is Actually Built to Solve

The Agentic Communication and Control Protocol, AC2 for short, addresses a governance gap that email, Slack, and Telegram were never designed to handle. Those channels can log that an agent sent a message or that a human replied "yes," but they provide no cryptographic proof of who authorized a specific action, and they offer no standardized way to hand an agent narrow, revocable authority instead of a blanket credential. As AI agents move from drafting suggestions to executing payments, signing code commits, and calling authenticated APIs, that gap turns into a real liability. An agent, plugin, or dependency compromised while holding a private key or a persistent API token can cause damage that's immediate and often irreversible, not just embarrassing.

Marc Vanlerberghe, the Algorand Foundation's Chief Strategy and Marketing Officer, framed the design choice bluntly in the launch announcement: "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." That's the entire thesis of the protocol in one sentence, and it's worth noting how unglamorous it is. AC2 isn't trying to make agents smarter or more autonomous. It's trying to keep a specific, narrow point of human control intact as agents get more capable.

Inside the Architecture: WebRTC, DIDComm, and Passkeys

Mechanically, AC2 establishes a direct, end-to-end encrypted WebRTC connection between an AI agent and a user's wallet or app, with no central message relay sitting in between. Messages are formatted using DIDComm v2.0, a decentralized identifier communication standard, which gives both sides a way to verify who they're actually talking to without relying on a shared intermediary. Authentication runs through Liquid Auth, built on the FIDO2 and WebAuthn standards, meaning a user approves requests with a passkey on a device they already control rather than typing a password into an agent-facing interface.

The signing flow itself is simple to describe even though the plumbing underneath isn't: an agent that needs to perform a signing operation, a payment, a git commit, an API authorization, sends a structured request over this encrypted channel. The request lands on the user's own device. The user reviews it, and if they approve, they sign it there, and only the resulting signature, not the private key, goes back to the agent. The credential never enters the agent's runtime at any point in the process. That's the entire security model: separate the ability to prepare an action from the authority to execute it, and keep the second piece permanently outside the agent's reach.

What Approval Actually Looks Like

AC2 supports a wide enough range of workflows that "signing" ends up covering more than payments. A coding agent can draft a change, open a pull request, and route the final publish signature to the developer for approval before it ships. A payment assistant can assemble a full transaction, amount, destination, and any accompanying data, and send it to a user's wallet for review rather than executing it directly. A shopping agent can go a step further and construct what the protocol calls an AP2 Intent Mandate: a scoped authorization defining the specific product, price ceiling, and conditions the agent is allowed to act on, which the user signs off on before the agent completes the purchase autonomously within those bounds.

Because the protocol is built to be extended, none of that list is fixed. Any message type or signing format can be added on top of the base specification, which is the difference between a single-purpose payment tool and something meant to sit underneath an entire category of agent behavior. Alongside the spec and reference implementation, published at github.com/algorandfoundation/ac2, the Foundation shipped an open-source proof-of-concept wallet from Pera and an OpenClaw plugin, giving developers a working agent framework to test signature requests against instead of just documentation.

AC2 and x402: Two Layers, Not One Answer

This site covered Algorand's x402 protocol back in July, and it's worth being precise about how the two relate, because they sound similar and solve different problems. x402 is a payment execution rail: it lets an agent hit an HTTP 402 response, pay for an API call or a digital resource on-chain, and continue its task without a human in the loop for that specific transaction. It's designed to remove friction from machine-to-machine payments happening at a pace no person could reasonably review one by one.

AC2 sits at a different layer entirely. It's not trying to make payments faster or more autonomous, it's reinserting a deliberate human checkpoint at the exact moment an agent needs signing authority for something consequential. The two aren't competing visions of how agentic commerce should work, they're addressing different tiers of risk within the same problem. A routine, low-value API payment is a reasonable candidate for x402's frictionless flow. A large transfer, a code deployment, or an open-ended purchase authorization is a better candidate for an AC2 approval step. Whether Algorand's own tooling ends up drawing that line automatically, or leaves it to individual wallets and agent frameworks to decide, is an open question the Foundation hasn't answered yet. But taken together, the two protocols suggest Algorand is building both ends of the agentic commerce stack: one for speed, one for control.

What AC2 Doesn't Solve

The Foundation's own launch materials, and the more skeptical trade coverage that followed, are candid about the limits here, which is worth taking seriously rather than glossing over. AC2 proves who approved a request. It does not evaluate whether that request was a good idea. A user can still sign a malicious, misleading, or badly constructed transaction if the wallet interface doesn't clearly surface the destination, amount, and consequences before asking for a signature. Cryptographic proof of consent is not the same thing as proof of informed consent, and the protocol has no mechanism to close that gap on its own. That responsibility sits with wallet UX, not with AC2's message format.

There's a second, more structural tension: approval fatigue. Requiring a fresh signature for every payment, commit, or API call preserves tight oversight, but it also means a user running an active agent could face frequent interruptions. The current version of AC2 only supports per-action signing. The Foundation has already flagged a future iteration aimed at "bounded delegation," where a user pre-authorizes a category of activity, a spending ceiling, a set of permitted counterparties, a time window, and lets the agent operate inside those limits without a prompt for every single action, escalating only when something falls outside the boundary. That's a meaningfully harder problem to specify precisely, since spending limits, counterparties, and revocation all need to mean the same thing to the user, the agent, and whatever service is on the other end of the transaction. It's not built yet.

Adoption is the other open variable. An open specification only becomes a real standard once wallets, agent frameworks, and service providers implement it consistently rather than treating it as one option among several. Releasing a spec, a reference wallet, and a developer plugin is the start of that process, not evidence that it's already happened. The Foundation says it's actively inviting design partners to review and contribute to the spec, which suggests this is still closer to draft-standard territory than settled infrastructure.