AC2 is an open standard that puts users back in control of AI-driven signing operations, providing verifiable proof of intent and credential isolation.
The problem: a compromised agent runtime (e.g. a malicious plugin dependency) can leak everything injected into it like API keys or session tokens, and there's no way to prove whether a human actually approved what happened, since chat-based "approvals" are just messages, spoofable and session-hijackable.
AC2 closes both gaps. Approvals become a FIDO2 passkey signature from your device, that's hardware-bound, phishing-resistant, and a real audit trail instead of a chat message. And credentials never enter the runtime at all: the agent gets a signed authorization, not the key. Compromise the runtime, there's nothing to steal.
Under the hood: AC2 opens a direct, end-to-end encrypted WebRTC connection between a user's wallet and an agent. When the agent needs to sign something (a payment, a commit, an API call), it sends the request via AC2, the user approves from their own wallet, and the signature is delegated back. The private key never leaves the user's device.
Built on three open standards: DIDComm v2.0 (messaging), WebAuthn/FIDO2 (hardware-bound auth), and WebRTC DataChannel (P2P transport, no relay servers). Lightweight (~50 lines for a basic flow), blockchain-agnostic, and works alongside your existing setup. One plugin, one command.
Built by the Algorand Foundation team behind Pera Wallet, Rocca, Intermezzo, and LiquidAuth. Use cases include code deploys, client comms, API access, x402 payments, and intent-based delegation via AP2 IntentMandates.
Spec is live and open. Reference implementation (AC2 Wallet) is on GitHub, Play Store, and App Store, with a plugin to try the full flow. This is v1, feedback welcome.
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.
Obviously it's using Algorand because it's built by people using Algorand, but regardless, wouldn't this all be possible to build without any cryptocurrency at all? And if no, why is Algorand particularly well suited for this (if it is), in contrast with anything else, say zCash or whatever?
Good questions, the core doesn't need a blockchain at all. AC2 is just an approval/signing layer (DIDComm + WebAuthn/FIDO2 + WebRTC), so most use cases like API access, git commits, and client comms never touch a chain. Blockchain only enters when what's being signed is a transaction, like an x402 payment.
For that case we use Algorand, but AC2 is chain-agnostic, meaning any chain could plug in. Algorand fit because of instant finality (no forking), low predictable fees for frequent small agent payments, and post-quantum resilient signatures. zCash optimizes for privacy, which isn't really our problem, we care about speed/finality for agent-authorized actions, not hiding the payment.
So the blockchain piece is more of a plugin for one use case than the foundation of the protocol. Hope that answers your questions!
As long as you can prove that a real human "approved" sharing the God-mode long-lived token with the keys to kingdom with an LLM, it's all good and we're secure?
This is the state of the art of computer security?
I can’t help but see the crypto stink all over this and recoil. This is just trying to salvage ideas and tools from the last fad into the current one.
> Disclaimer: AC2 is a self-custodial Algorand wallet. You — and only you — hold your seed phrase, your keys, and your crypto-assets on your own device. Pera Wallet, Lda does not hold, custody, or have access to your seed phrase, your keys, or your crypto-assets, and cannot recover them on your behalf.
> Seems like “ask for approval, except you approve by spending a little of some random altcoin”
Is that actually what the text explicitly says? I'm not getting the same impression from the protocol they suggest, where is the spending happening?
AFAIK, they're using the cryptographic primitives from Algorand for signing, no transactions required to approve stuff. But happy to be shown otherwise, I might have misunderstood.
Regardless of what people think of blockchains, it's the necessary foundation for any agent governance. If not this protocol, then something in this direction.
The analogy I would use is the only thing reliably containing humanity is interstellar distances, and the equivalent for ASI would be cryptographic distances, where the only way to relate to anything safely will be via a crypto interface. Compute is the physics of an ASI's substrate, and cryptography is the only meaningful barrier we've been able to create in it so far.
For me, the word "protocol" implies interoperability, but "Get Started" only mentions installing an OpenClaw plugin, and the documentation link leads to a GitHub project with a pretty much empty README that doesn't explain anything. Practically, as someone willing to adopt the protocol, I'd like to know how I can integrate it into my existing agent harness and connect it to an upstream server. The landing page says that an agent runtime can be i theory compromised (the reason we propose a protocol like this), but I don't see any explanation for why the AC2 library that does the heavy lifting can't be compromised too.
Interesting approach to agent security cryptographic proof of intent and hardware-bound approvals could make human-in-the-loop controls far more trustworthy.
Signing proves a human approved X after the fact. It doesn't answer whether X should have reached a human at all. Those are different problems one's accountability, the other's judgment.
15 comments
[ 0.16 ms ] story [ 6.1 ms ] threadThe problem: a compromised agent runtime (e.g. a malicious plugin dependency) can leak everything injected into it like API keys or session tokens, and there's no way to prove whether a human actually approved what happened, since chat-based "approvals" are just messages, spoofable and session-hijackable.
AC2 closes both gaps. Approvals become a FIDO2 passkey signature from your device, that's hardware-bound, phishing-resistant, and a real audit trail instead of a chat message. And credentials never enter the runtime at all: the agent gets a signed authorization, not the key. Compromise the runtime, there's nothing to steal.
Under the hood: AC2 opens a direct, end-to-end encrypted WebRTC connection between a user's wallet and an agent. When the agent needs to sign something (a payment, a commit, an API call), it sends the request via AC2, the user approves from their own wallet, and the signature is delegated back. The private key never leaves the user's device.
Built on three open standards: DIDComm v2.0 (messaging), WebAuthn/FIDO2 (hardware-bound auth), and WebRTC DataChannel (P2P transport, no relay servers). Lightweight (~50 lines for a basic flow), blockchain-agnostic, and works alongside your existing setup. One plugin, one command.
Built by the Algorand Foundation team behind Pera Wallet, Rocca, Intermezzo, and LiquidAuth. Use cases include code deploys, client comms, API access, x402 payments, and intent-based delegation via AP2 IntentMandates.
Spec is live and open. Reference implementation (AC2 Wallet) is on GitHub, Play Store, and App Store, with a plugin to try the full flow. This is v1, feedback welcome.
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.
For that case we use Algorand, but AC2 is chain-agnostic, meaning any chain could plug in. Algorand fit because of instant finality (no forking), low predictable fees for frequent small agent payments, and post-quantum resilient signatures. zCash optimizes for privacy, which isn't really our problem, we care about speed/finality for agent-authorized actions, not hiding the payment.
So the blockchain piece is more of a plugin for one use case than the foundation of the protocol. Hope that answers your questions!
As long as you can prove that a real human "approved" sharing the God-mode long-lived token with the keys to kingdom with an LLM, it's all good and we're secure?
This is the state of the art of computer security?
Is that actually what the text explicitly says? I'm not getting the same impression from the protocol they suggest, where is the spending happening?
AFAIK, they're using the cryptographic primitives from Algorand for signing, no transactions required to approve stuff. But happy to be shown otherwise, I might have misunderstood.
/ignore
The analogy I would use is the only thing reliably containing humanity is interstellar distances, and the equivalent for ASI would be cryptographic distances, where the only way to relate to anything safely will be via a crypto interface. Compute is the physics of an ASI's substrate, and cryptography is the only meaningful barrier we've been able to create in it so far.