Tracing authority through AC2’s user-controlled signing flow

Algorand Foundation announced AC2’s public launch on August 25 with a specification and reference implementation. Its announcement describes signing requests that users review while their private keys remain under their control (launch announcement). That establishes what was announced, not whether a particular deployment preserves the boundary correctly.

The AC2 draft documents the intended exchange: authenticated peer-to-peer messaging carries a signing request to a user, the user reviews it in a wallet or application, and a signature returns to the agent while the key stays with the user (AC2 draft). Within that flow, the returned signature and the retained credential are distinct objects. That distinction cannot be generalized to every approval design; another system could return a reusable credential or a broadly reusable authorization artifact.

For operators, the practical question is narrower: does a specific implementation preserve the documented custody boundary while binding the returned authority to the action the user reviewed?

Build the review around three records

A useful review can connect three records:

reviewed request → executable authority → execution evidence

This is an SGL architecture prescription derived from the documented mechanisms, not a review method specified by AC2. Each record answers a different question: what the user saw, what the executor could do, and what the system can later demonstrate.

Record what the user reviewed

Capture the operation presented for approval and the data that identifies it. Depending on the application, the record may include a target resource, action, payload digest, destination, amount, environment, expiry, or nonce. These are design-review examples, not fields established by the supplied drafts.

Then compare that record with the material bound to the signature. If an execution-relevant field can change without invalidating the approval, the key may remain with the user while the authorized action remains too broad. A displayed destination and a cryptographically permitted destination must not silently diverge.

Identify the authority the executor receives

In AC2’s documented flow, the user returns a signature and retains the key. Reviewers still need to determine what that signature authorizes, how long it remains useful, and where it can be presented. Key custody alone does not establish narrow execution scope.

An independent IETF Internet-Draft documents another delegation design. It defines short-lived, proof-of-possession-bound tokens, capability constraints, opaque handles in place of credentials, and signed receipts linking attenuated delegation hops to root consent (credential-delegation draft). It is a draft design, not a finalized standard or an independently validated operating result.

The draft’s opaque handles also do not establish safe custody by themselves. An implementation review would need to identify what resolves a handle, which caller can invoke it, and which constraints survive resolution. Those are questions raised by the mechanism, not observed properties of deployed systems.

Preserve evidence of the final action

Trace how the executor checks freshness, audience, proof of possession, and capability scope before acting. These are proposed review targets; the supplied evidence does not demonstrate their behavior in a production integration.

The IETF draft’s signed receipts suggest a related review objective: retain a verifiable relationship among root consent, each attenuation of authority, and the final action. A receipt is not automatically a complete audit trail. Reviewers can inspect whether retained evidence identifies the delegated capability, participating identities, validity interval, proof binding, and terminal action. These fields and retention questions are SGL inspection criteria, not claims about the draft’s complete receipt schema.

Mutate the path to expose weak binding

A successful signature shows that one path completed. It does not show that altered authority will be rejected. A focused test campaign can change one condition at a time:

• Change an execution-relevant field after approval.
• Replay an approval after its intended validity window.
• Present the approval to a different executor.
• Replace the proof-of-possession key where that mechanism applies.
• Broaden a capability after an attenuation hop.
• Remove one receipt from a delegation chain.

Expected outcomes depend on the protocol and application policy. Before testing, the team can name the verifier expected to reject each mutation and the artifact expected to record that rejection. The supplied sources neither prescribe these cases nor report their results.

Label the evidence before making the claim

The review should keep three evidence levels distinct:

• Protocol intent: what a specification or draft describes.
• Implementation evidence: what code and tests demonstrate for a specific build.
• Deployment evidence: what a configured environment records during execution.

AC2’s launch announcement establishes an announced specification and reference implementation. The two drafts document mechanisms for user-controlled signing or constrained delegation. None of the supplied excerpts establishes that a particular production system enforces those mechanisms end to end.

For payments, code signing, and privileged APIs, the decision should therefore rest on the connected records, not on the approval screen alone. Show what the user reviewed, demonstrate the exact authority the executor accepted, and retain evidence of the resulting action and any delegation hops. Teams applying that review to a concrete agent integration can carry the same custody, binding, and rejection questions into a scoped build review.