AC2 is an open standard that puts users back in control of AI-driven signing operations, providing both verifiable proof of intent and credential isolation.
A developer we know runs an AI agent that handles pull request reviews, merge prep, and runs tests. It’s a good setup that saves hours of time in today’s autonomous world.
But then: someone compromised their agent's runtime. It wasn’t a sophisticated attack, just a malicious dependency in a plugin. The attacker got everything the agent had, including the API keys injected at startup, the session tokens for the approval flow, and enough access to push a merge that it looked like the lead engineer had approved.
The team couldn't prove a human hadn’t actually approved it, because the approval was a message in a Slack thread, and the credentials were sitting in the runtime environment. There was no way to verify what was real and what wasn't.
This one incident exposes two gaps that exist in most agent systems today:
- there was no cryptographic proof that a human had actually authorized the action, and
- the agent had access to credentials that should never have been exposed in the first place.
Enter: AC2 Protocol
Agentic Communication & Control Protocol (AC2) is an open protocol that closes both of these gaps.
AC2 gives agent approvals something they currently lack: a cryptographic signature that proves a real human authorized a specific action. Your agent sends a request, you review it on your device, and your approval is a FIDO2 passkey signature. Hardware-bound, phishing and forgery-resistant. Not a chat message – a verifiable audit trail.
AC2 also changes where your credentials live. Instead of injecting API keys into the agent's runtime, and then trying to harden your runtime, AC2 keeps them on your device to begin with. The agent gets signed authorization, not the credential itself. If the runtime is compromised, there's no API keys to steal.
In practice, AC2 establishes a direct, end-to-end encrypted WebRTC connection between a user's wallet or app and an AI agent. When an agent needs to perform a signing operation – for example a payment, a git commit, or an API authorization – it sends a request to the user via AC2. The user reviews and approves through their own wallet interface, and the signature is delegated back to the agent. The private key never leaves the user's control.
AC2 is lightweight – just about fifty lines for a basic flow – and blockchain-agnostic. No containers, no messaging SDK, no credential proxy. AC2 works alongside your existing setup.
Why your current agent approvals aren't enough
Your approvals can be spoofed.
Chat-based confirmations – like in Whatsapp, Telegram, or Slack – rely on session tokens that have been bypassed by multiple CVEs in 2026. Prompt injection can trick agents into self-approving. A button tap is spoofable, session-hijackable, and invisible to anyone outside the conversation. There's no true accountability. A simple chat "yes" doesn't prove who sent it, when, or what they were approving.
Your credentials are exposed.
Most agent setups inject API keys, tokens, and secrets at runtime. The agent needs to access a service, so it gets the key. When the runtime is compromised, and it has been, repeatedly, those credentials are gone. Not just the session. Your actual keys. The current model is inject and hope. That's not a security architecture.
How AC2 works
AC2 Protocol is powered by three open standards, chosen deliberately:
- DIDComm v2.0 for message formatting – any framework that constructs a DIDComm message speaks AC2.
- WebAuthn/FIDO2 for authentication – signatures bound to physical hardware (TPM, Secure Enclave), not app-level tokens.
- WebRTC DataChannel for transport – P2P after initial handshake. No relay servers.
Integration is one plugin and one command for a basic approval flow. AC2 works alongside existing setups, upgrading the trust level, not the workflow.
Why Algorand Foundation and Pera Wallet built AC2
The Algorand Foundation team has spent years building secure authentication and P2P communication products including Pera wallet, Rocca, Intermezzo, and LiquidAuth (open-source FIDO2 + WebRTC). When we looked at agent approvals, the gap was clear: there were plenty of approval flows, zero approval proof.
AC2 wraps our proven auth infrastructure in a protocol designed for agents.
What you can do with AC2:
- Code deploys: An agent prepares a commit or deploy and requests a signature before pushing. The signature proves exactly what was reviewed and approved.
- Client communications: An agent drafts content and requests sign-off before sending. The signature proves the specific message was human-approved.
- API access: An agent presents the request parameters for approval before execution. The signature proves what was authorized, by whom, and when.
- x402 payments: An agent sends payment details to the user's wallet for approval before completing the API call. The signature proves authorization without exposing private keys.
- Intent-based actions: An agent submits an AP2 IntentMandate defining what it may do and under what constraints. Once signed, it can act autonomously within those cryptographically enforced limits.
What's next: delegation, not just approval
AC2 currently prompts for every signature, but this safe default is not the most autonomous one. The next iteration adds delegation that lets you define bounds once, rather than approving every single action from scratch. Inside those bounds, the agent acts freely. Outside them, it still comes back to you. The security model doesn't change as the agent still never gets your keys, just how often you're asked.
Try AC2
AC2 can easily be added to any agentic SDK/wallet. If you're building agent tools and your users need verifiable approvals, not just approval steps, AC2 gives you that layer without building it from scratch.
The spec is live – and open. A reference implementation, AC2 Wallet, is available on GitHub, as well as on the Play Store and Apple’s App Store along with a complimentary AC2 plugin, if you want to see the full approval flow in action.
This is the first version. We welcome feedback on how the protocol can help secure human-agent communications and build trust in the agentic ecosystem. Any agent platform or identity wallet provider should be able to communicate with AC2 without custom plugins, exposed credentials, or proprietary approval flows.
Disclaimer: The content provided in this blog is for informational purposes only. The information is provided by the Algorand Foundation and while we strive to keep the information up-to-date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the blog or the information, products, services, or related graphics contained in the blog for any purpose. Any forward-looking statements are subject to change. The content of this blog is not intended to be legal, financial, or investment advice nor is it an endorsement, guarantee, or investment recommendation. You should not take any action before conducting your own research or consulting with a qualified professional. Any reliance you place on such information is therefore strictly at your own risk. All companies are independent entities solely responsible for their operations, marketing, and compliance with applicable laws and regulations. In no event will Algorand Foundation nor any affiliates be liable for any loss or damage including without limitation, indirect, or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this blog. Through this blog, you may be able to link to other websites which are not under the control of the Algorand Foundation. We have no control over the nature, content, and availability of those sites. The inclusion of any links does not imply a recommendation nor endorse the views expressed therein. Any statements about future plans, integrations, or protocol upgrades are forward-looking and subject to change. The use of agentic commerce involves risks, including potential fraud and identity verification issues. Users and merchants should ensure they are using verified agents and follow best practices for security and compliance.