Give the Agent Authorization, Not the Key

Agent approval systems often collapse two separate questions: who authorized this action, and what credential lets the system perform it?

Algorand Foundation's new Agentic Communication & Control Protocol, or AC2, makes that separation explicit. An agent prepares a signing request. A person reviews it in a wallet or application that retains the private key. The agent receives a signature for the requested payload rather than possession of the credential itself.

The protocol is early and its strongest claims are still design claims, not independent security results. But its shape matters. It treats human approval as a portable cryptographic artifact and credential custody as a separate control plane.

Approval should produce evidence, not just a message

Most human-in-the-loop systems record an approval as application state: a button changed status, a chat reply said yes or a workflow resumed after a callback. That can be useful operational evidence, but it may not prove which person approved the exact payload that was later executed.

AC2 proposes a narrower contract. The agent sends a structured signing request containing the operation and the data to be signed. The controller reviews the request and returns a digital signature. The protocol's draft specification requires agents to request signatures rather than access a controller's private keys, and its examples cover payments, signed code commits and documents.

The launch implementation combines DIDComm-compatible message formats, passkey authentication through WebAuthn/FIDO2 and an encrypted WebRTC DataChannel. A signaling service establishes the initial connection, but application messages are intended to travel directly between controller and agent after the handshake.

This produces a record that can be checked independently of the model's explanation. A verifier can ask whether a known key signed this exact payload. The answer does not depend on whether the agent accurately remembers the conversation that preceded it.

The agent should carry proof of authority for the action, not the credential that creates authority.

Sources: Algorand Foundation's AC2 launch (opens in a new tab) and the draft AC2 specification (opens in a new tab).

Credential isolation changes the compromise boundary

The more important architectural move is where the key does not go.

If an agent runtime holds an API token or private key, any compromise of that runtime may inherit the credential's full power and lifetime. Adding an approval step inside the same environment does not remove that exposure. The process that asks for permission can still be the process that possesses the key.

AC2 instead keeps signing material with the controller. The agent receives the resulting signature, scoped by the payload the user approved. A compromised runtime may still misuse any valid signature it receives, misrepresent a request to the user or exploit an overly broad payload. It should not automatically obtain the underlying private key merely because the agent needs to execute a signed operation.

That distinction is useful beyond wallets. The same pattern can mediate a deployment, an API request, a client communication or any other action for which a separate signer can authorize a concrete payload. It resembles capability-based control: give the worker the smallest artifact needed for the next effect, not the reusable secret from which many effects can be created.

A signature proves less than an approval interface suggests

Cryptographic evidence is precise, but its meaning is narrow.

A valid signature can establish that a key signed a particular byte sequence. It does not establish that the person understood the request, that the wallet displayed the same semantics as the encoded payload, that the request complied with policy or that the resulting action was safe. Those properties depend on canonical encoding, trustworthy presentation, principal mapping, policy evaluation and execution-time verification.

The controller therefore needs more than an approve button. It needs an intelligible description of the requested effect, the exact target and parameters, any expiry or scope, and a stable binding between what is displayed and what is signed. The executor must then verify that the signature authorizes the action it is about to perform—not a transformed, replayed or adjacent action.

Receipts also remain necessary. A signed request records intent before execution. A completion record should bind that intent to the actual effect, including the resource changed, the result, the time and any material deviation. Authorization and execution evidence answer different questions.

The safe default is deliberately interruptive

The current AC2 version asks the user to sign each operation. Algorand Foundation describes bounded delegation as a future iteration: a user would sign constraints once, and the agent could operate inside them without returning for every action.

That roadmap exposes the central governance tradeoff. Per-action approval has a clear authority boundary but can create fatigue and bottlenecks. Delegation improves autonomy but introduces policy compilation, expiry, revocation, budget accounting and ambiguity at the edge of a grant.

The right next step is not a generic permission to proceed. A delegation should identify the principal, agent, allowed action classes, targets, limits, duration, revocation state and evidence required at execution. It should fail closed when the current request cannot be shown to fit the grant.

Until that model exists and is validated, the interruptive default is an honest representation of the protocol's maturity. It solves a smaller problem: move a signature request across an authenticated channel while keeping the signing key outside the agent.

Build the authorization boundary around the signed object

AC2 suggests four practical requirements for governed agent systems.

First, separate intent, authorization and execution. The agent may propose an action, but a distinct principal or policy engine grants authority, and the executor verifies that grant immediately before the effect.

Second, keep credentials out of general-purpose agent runtimes wherever possible. Replace ambient reusable secrets with short-lived, operation-bound capabilities or signatures.

Third, make the signed payload reviewable and deterministic. A human-readable screen and the machine-executed bytes must describe the same action. Version the schema, canonicalize the encoding and reject unknown or omitted fields.

Fourth, preserve both sides of the transition. Store the request, signer identity, signed payload, signature, execution result and any rejection or expiry. Do not store private keys or treat a prior approval as authority for a later request.

The protocol does not make an agent trustworthy. It makes one part of the trust boundary more explicit: the agent can ask for authority without becoming the custodian of the authority-producing key.

Sources and limitations

• Introducing AC2 Protocol: The missing security layer for AI agents (opens in a new tab)
• AC2 draft specification and reference implementation (opens in a new tab)

The evidence is first-party launch material, a draft specification and an early reference implementation. It is not an independent security audit, interoperability test or production-adoption study. The specification marks conformance and terminology as incomplete, and its security model assumes a semi-trusted agent and a controller who reviews every signing operation. Although the launch describes AC2 as open, the public repository did not expose a detected software license when verified, so reuse rights for the implementation should be confirmed before adoption.

The launch post's compromised-runtime story is presented without enough public evidence to verify it as an incident, so it is not used here as a factual case study. Claims that the protocol is blockchain-agnostic, lightweight or compatible with any agent platform remain vendor claims pending independent implementations and tests.

AC2 keeps private keys outside the agent by design, but the wallet, controller device, signaling path, identity binding, request presentation, signature format, executor and agent plugin remain security-sensitive surfaces. A signature proves control of a key over a payload; it does not by itself prove informed consent, policy compliance, semantic correctness or safe execution. The current release requires per-signature approval, while bounded delegation is described as future work.