The AC2 protocol is designed to let users review and authorise AI agent actions without transferring private keys to the agent’s runtime. /Image courtesy of the Algorand Foundation
The Algorand Foundation said on August 25 in Dover, Delaware, that it had released the Agentic Communication and Control Protocol (AC2), an open-source standard that allows users to approve signing requests from artificial intelligence agents without transferring their private keys to them.
AC2 addresses a growing governance problem as AI agents begin handling payments, software deployment and application programming interface (API) authorisations. Agents need sufficient permissions to complete tasks, but storing private keys, API credentials or session tokens inside their runtime increases the potential damage if an agent, plugin or software dependency is compromised. Email and messaging applications may record a response, but they do not necessarily provide cryptographic proof of who authorised a particular action.
Under AC2, an agent sends a signing request to a user’s wallet or application. The user reviews the details and signs on a personal device, after which the authorisation is returned to the agent. The private key remains with the user rather than being stored in the agent environment.
The protocol is blockchain-agnostic and does not require a blockchain to operate. Its specification and reference implementation have been released alongside a proof-of-concept wallet and an OpenClaw plugin for developer testing.
Separating agent capability from signing authority
AC2 uses Decentralized Identifier Communication version 2.0 (DIDComm v2.0) message formats, Web Real-Time Communication (WebRTC) for encrypted peer-to-peer data exchange and authentication based on Fast Identity Online 2 and Web Authentication standards (FIDO2/WebAuthn). These components are intended to establish an authenticated communication channel between an agent and a user-controlled device.
The architecture separates an agent’s ability to prepare an action from the permission required to execute it. A coding agent could draft a software change but request the developer’s signature before publication. A payment assistant could assemble transaction details and send them to a digital wallet for review, while a shopping agent could prepare an intent mandate defining the permitted product, price and conditions.
This distinction matters as agentic systems progress from making recommendations to initiating transactions. An inaccurate chatbot response creates an information risk. An agent holding a private key or persistent credential can cause an irreversible financial or operational consequence.
AC2 does not determine whether a proposed action is appropriate. It provides a communication and signing layer intended to establish who approved a specific request while keeping the underlying credential outside the agent runtime. The resulting signature can create a more verifiable audit record than a confirmation delivered through an ordinary chat message.
User approval does not eliminate transaction risk
Keeping private keys outside an AI agent reduces one form of credential exposure, but it does not make every signed action safe. A user may still authorise a malicious, misleading or incorrectly constructed transaction if the wallet does not clearly present its destination, amount, permissions and consequences. Cryptographic proof can establish that approval occurred; it cannot show that the user fully understood the request.
The design also creates tension between security and autonomy. Requiring a signature for every payment, code commit or API request preserves direct oversight, but frequent prompts can produce approval fatigue. Users repeatedly presented with complex requests may begin confirming them without adequate review.
The current version of AC2 requests a signature for each action, while a future iteration is expected to support bounded delegation. Users would define permitted activities in advance, allowing agents to operate within those conditions while requiring additional consent for exceptions.
This model could make AC2 more practical for high-frequency workflows, but the boundaries would need to be precise. Spending ceilings, permitted counterparties, time periods, transaction types and revocation procedures must be expressed in terms that users, agents and service providers interpret consistently.
Interoperability presents another test. AC2 uses established identity, authentication and communications technologies, but an open specification becomes an industry standard only when wallets, agent frameworks and service providers implement it consistently. The release of a specification, reference wallet and testing plugin begins that process but does not yet demonstrate broad adoption.
AC2 reflects a wider challenge in AI security. The central issue is not only whether an agent can complete a task, but what it is authorised to do, where its credentials are held and how a human decision can later be verified. As AI agents acquire the ability to spend money, publish code and authorise digital operations, the control layer between a proposed action and its execution may become as consequential as the intelligence of the agent itself.
