Feat: Add enhancements, Update enforcement mechanisms and Add MPP by emg110 · Pull Request #2 · algorandfoundation/ac2

emg110 · 2026-04-27T10:12:09Z

This PR provides:

General edits and enhancements
Addition and completion of enforcement mechanisms
Adding MPP to supported use cases
Adding extension architecture support to the core AC2 spec, and based on that, add pre-authorized payments and asset transfer extension for guard-railed autonomous agent payments and asset transfers.

Note: After this PR merger, two upcoming extensions are ready to be pushed:

AC2 Discovery extension (complying to Bazaar and MPP discovery specs)
AC2 A2A extension and Agent-to-agent communication and control
AC2 AP2 extension to provide AP2 Verifiable Credential signing using AC2

…es to support extension architecture), Add pre-authorized extension

ehanoc · 2026-04-27T11:51:11Z

+The protocol supports both real-time streaming for AI interactions (voice, text, or video from the Controller to the agent; voice, text, or file artifacts back from the agent) and request/response patterns for discrete operations. AC2 uses **DIDComm-compliant message formats** [[didcomm-messaging](https://identity.foundation/didcomm-messaging/spec/)], enabling interoperability with existing decentralized identity infrastructure while extending the protocol for real-time streaming use cases.

-Authentication leverages Decentralized Identifiers (DIDs) with Passkey-based credentials, providing phishing-resistant security without passwords. AC2 is use-case agnostic, supporting web3 workflows (x402 payments), code signing (git commits), document signatures, and any other digital signing operation where the user holds the keys.
+Authentication leverages Decentralized Identifiers (DIDs) with Passkey-based credentials, providing phishing-resistant security without passwords. AC2 is use-case agnostic, supporting web3 workflows (x402 payments, MPP machine payments — both `charge` and `session` intents), code signing (git commits), document signatures, and any other digital signing operation where the signing key is held by the user and the signature is requested per-operation. Operations on keys held by the agent's tooling, including autonomous operation within pre-authorized bounds, are defined by separate AC2 extensions.


Operations on keys held by the agent's tooling, including autonomous operation within pre-authorized bounds, are defined by separate AC2 extensions. I would remove this section. pre-auth and extensions isn't something we would like to ship for v1

ehanoc · 2026-04-27T11:52:00Z

 ## Abstract

-This specification defines the **AC2 (Agentic Communication and Control) Protocol**, a peer-to-peer authenticated messaging system designed for secure communication between users and AI agents. AC2 enables human-in-the-loop digital signing operations, where agents can request signatures from users, who validate and approve through their own wallet or application, with signatures then delegated back to the agent for continued operations.
+This specification defines the **AC2 (Agentic Communication and Control) Protocol**, a peer-to-peer authenticated messaging system designed for secure communication between users and AI agents. The core protocol covers human-in-the-loop signing — agents request signatures from users, who validate and approve through their own wallet or application, with signatures then returned to the agent. The agent itself holds no keys and never sees key material; key custody for the agent's own identity lives in the agent's tooling (e.g., agent-internal tools, MCP tools, or OWS wallet toolings). Additional capabilities such as autonomous operation under pre-authorized bounds are defined as separate extensions to this core (see **Extensions** below).


Can we keep the paragraph as it was?

ehanoc · 2026-04-27T11:53:26Z

- Agents CANNOT sign transactions autonomously
- Users maintain control of their keys at all times
- Agents request operations, users approve via familiar interfaces
+- Agents MUST NOT access the user's private keys and MUST NOT sign on the user's account


This line feel redundant . They can't access them anyway if they are in a users wallet.

ehanoc · 2026-04-27T11:55:46Z

- Agents request operations, users approve via familiar interfaces
+- Agents MUST NOT access the user's private keys and MUST NOT sign on the user's account
+- For operations requiring the user's key, agents request and the user approves via familiar interfaces
+- The agent itself holds no keys; key custody for the agent's own identity lives in the agent's tooling


key custody for the agent's own identity lives in the agent's tooling - We don't want to define this. But to the user

This sentence is there to dissambiguate regarding the fact that protocol asserts of keys being held only by user and using DIDCOMM requires agent to have a DID and autonomous agent payments demand agents to have signing power used for both blockchain and non-blockchaion operations (arbitrary data signing and DID authentication). Since the PR to spec requires Agent having a DID and a signing key. This sentence asserts that Agent keys are not held by AC2 supporting clients.
May I suggest a replacement instead: "AC2 does does not concern with how agents manage their own keys and DIDs as long as standard Keys and DIDs are used"

ehanoc · 2026-04-27T11:55:59Z

+- Agents MUST NOT access the user's private keys and MUST NOT sign on the user's account
+- For operations requiring the user's key, agents request and the user approves via familiar interfaces
+- The agent itself holds no keys; key custody for the agent's own identity lives in the agent's tooling
+- Extensions to this core MAY introduce additional flows such as autonomous operation under pre-authorized bounds


Let's not offer extensions for now

ehanoc · 2026-04-27T12:06:34Z

 }
 ```

+##### Capability List


No specific capabilities

It has been removed completely in latest update of PR

ehanoc · 2026-04-27T12:07:06Z

    "@context": ["https://ac2.io/v1"],
-    "type": "ac2/SessionEstablish",
-    // ...
+    "type": "ac2/CapabilityList",


no capabilities, this is up to the integrators

It has been removed completely in latest update of PR

ehanoc · 2026-04-27T12:07:30Z


 1. **DID Methods**: Implementations MUST support `did:key` per [[did-key](https://w3c-ccg.github.io/did-method-key/)] and SHOULD support `did:web`
-2. **Key Types**: Ed25519 keys REQUIRED for signatures; secp256k1 OPTIONAL for blockchain operations
+2. **Key Types**: Ed25519 keys REQUIRED for signatures; secp256k1 OPTIONAL for blockchain operations; post-quantum schemes such as `falcon-512` OPTIONAL


Quantum is an open question, this is a stretch. If we are crypto agile, it doesn't matter for now

Gladly will be removed

ehanoc · 2026-04-27T12:07:58Z

-4. **Discovery**: Agent DIDs MUST be discoverable via `.well-known/did.json` or equivalent
+4. **Discovery**: Agent DIDs MUST be discoverable via `.well-known/did.json` (for `did:web` DIDs) or `.well-known/did-configuration.json` per [[well-known-did-configuration](https://identity.foundation/.well-known/resources/did-configuration/)] (for any DID method, including `did:key`)
+
+### Agent DID Key Origin


We don't want to be prescriptive, this is outside the specification and avoid any Algorand specific standards.

ehanoc · 2026-04-27T12:08:56Z

 ```

-## Streaming Protocol
+## Extensions


No extensions for now

Copilot

Pull request overview

This PR updates the AC2 core specification to clarify core invariants, add an explicit extensions model (including MPP use cases), and introduces a new “Pre-Authorized Operations” extension for bounded autonomous payments/asset transfers.

Changes:

Refines AC2 core language around key custody, signature request semantics, and adds extension architecture + capability namespacing guidance.
Adds MPP (charge/session) use cases and related references.
Introduces ac2-ext-pre-authorized defining a Pre-Authorized pattern and messages for top-ups, grants, and spend receipts.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
ac2.md	Updates core AC2 protocol narrative, data model examples, and adds extension architecture + additional message examples.
ac2-ext-pre-authorized.md	New extension spec defining pre-authorized autonomous payment/transfer flows and associated DIDComm messages.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

emg110 · 2026-05-02T19:21:17Z

+## Extensions

-AC2 supports real-time streaming using a hybrid DIDComm approach: stream initiation uses standard DIDComm messages, while stream chunks use optimized lightweight framing over the established WebRTC DataChannel.
+AC2 is designed to be extended. Extensions add new communication patterns, message types, and behaviors on top of the core foundation (DID-based identity, Liquid Auth transport, DIDComm message format, the signing trio, plugin model). Discovery, streaming, attachments, and HITL approvals are extensions, not core.


fixed in 0cbcaa2

emg110 · 2026-05-02T19:22:51Z

+  "body": {
+    "reason": "Balance below threshold for pending x402 payments",
+    "chain": "algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=",
+    "asset": { "id": "31566704", "symbol": "USDC" },


Clarified the wording in 0cbcaa2

emg110 · 2026-05-02T19:24:01Z

+    "capabilities": ["mpp.charge", "mpp.session.voucher"],
+    "vaultPointer": "algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=/app/987654321/vault/NTRZR6HGMMZGYMJKUNVNLKLA427ACAVIPFNC6JHA5XNBQQHW7MWA",
+    "note": "LLM inference budget for April"


Fixed in 0cbcaa2

emg110 · 2026-05-02T19:24:18Z

+    "type": "ac2/SigningRequest",
+    "from": "did:example:agent",
+    "to": ["did:example:user"],
+    "created_time": Date.now(),


Fixed in 0cbcaa2

emg110 · 2026-05-02T19:24:43Z

    "signature": "base64-encoded signature",
+    "publicKey": "base64-encoded 32-byte ed25519 public key",
+    "address": "58-char Algorand address",
+    "keyType": "account"


Fixed in 0cbcaa2

emg110 · 2026-05-02T19:24:53Z

+```json
+"keyOrigin": {
+  "method": "arc52",
+  "derivationPath": "m/44'/283'/0'/0'/agent/0"


Fixed in 0cbcaa2

emg110 · 2026-05-02T19:25:08Z

+    "key_type": "ed25519" | "secp256k1" | "falcon-512",
+    "derivationPath": "m/44'/283'/0'/0'/agent/0",
+    "purpose": "<WHY_NEEDED>",
+    "for_operation": "<WHAT_OPERATION>"
+  }
 }
 ```

-### Key Provisioning
-
-Agents MAY request public keys from the controller for identity purposes:
+**KeyResponse** (Controller → tooling, via the agent over AC2):

 ```json
 {
-  "type": "ac2/KeyRequest",
-  "key_type": "ed25519" | "secp256k1" | "falcon-512"
-  "purpose": "<WHY_NEEDED>",
-  "for_operation": "<WHAT_OPERATION>"
+  "@context": ["https://ac2.io/v1"],
+  "type": "ac2/KeyResponse",
+  "from": "did:example:user",
+  "to": ["did:example:agent"],
+  "body": {
+    "status": "approved" | "rejected",
+    "derivationPath": "m/44'/283'/0'/0'/agent/0",
+    "key_type": "ed25519",
+    "material": "<BASE64_OR_ENCRYPTED_KEY_PAYLOAD>",
+    "publicKey": "<BASE64_PUBLIC_KEY>",
+    "reason": "<OPTIONAL_REJECTION_REASON>"


Fixed in 0cbcaa2

emg110 added 2 commits April 27, 2026 13:10

Update AC2 Spec (enforcement mechanisms, MPP examples, and some updat…

1925e93

…es to support extension architecture), Add pre-authorized extension

Remove capabilities and migrated those into discovery spec

3b5d77d

ehanoc requested changes May 2, 2026

View reviewed changes

ehanoc requested a review from Copilot May 2, 2026 15:21

Copilot started reviewing on behalf of ehanoc May 2, 2026 15:22 View session

Copilot AI reviewed May 2, 2026

View reviewed changes

Address Copilot Review Comments

0cbcaa2

Conversation

emg110 commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

emg110 commented Apr 27, 2026 •

edited

Loading