AI & Agentic Infrastructure

Agent wallet authorization

What it is: Agent wallet authorization is issuer policy on whether a signed payment payload may move value—wallet authentication proves key possession; authorization proves the spend is permitted.

Below: signing boundaries, policy attachment, settlement references, and why possession of keys is not payment permission.

Wallets prove possession of keys; they do not, by themselves, prove that a payment was permitted. In agent stacks, that distinction blurs because the same component signs and talks to the user. Authorization is the rule set that says this signature may move this much value to this counterparty now—possession is only the first input.

Possession, permission, and settlement evidence

Wallet provisioning — Keys or tokens bound to agent handle.
Policy attachment — Spending controls and delegation references.
Sign attempt — Wallet signs only canonical payloads.
Issuer authorizes — Validates wallet tier, policy, and delegation.
Settlement — Evidence references wallet and rule IDs.

Where current systems fail

Hot wallets without policy attachment. Shared API keys mistaken for authorization. Missing settlement evidence for agent-initiated pulls.

Risks and attack surfaces

Key exfiltration — Hardware or HSM boundaries.
Partial signing — Malicious payloads if canonicalisation is wrong.

Wallets are where key hygiene meets product. If authorization policy is an afterthought, you will ship beautiful custody with ugly surprises at settlement.

How verification or authorization is enforced

Authorization checks wallet policy and delegation. Wallet authentication proves possession; authorization proves permission.

Where stateless verification applies

Verification of signatures and policy references without persisting user transaction history at the verifier.

How AffixIO approaches this

Wallets are constrained signers: they mint signatures only over canonical payloads the issuer will recognize. AffixIO treats key custody and authorization policy as orthogonal problems that meet at the signing boundary.

Policy attachment — Wallet tiers and limits are explicit inputs to authorization.
Settlement evidence — References point to wallet, delegation, and policy—not conversational context.
Failure containment — Key compromise is real; blast radius is bounded by what policy allows per handle.

Where this fits in agentic commerce

Issuer

Wallet tiering and risk.

Merchant

Sees only authorized attempts.

APIs

Programmatic wallet operations.

Edge / offline

Local signing with expiry.

What this system does not solve

Does not secure endpoints against full device compromise—only limits blast radius via policy.

Frequently asked questions

Is wallet authentication the same as authorization?

No. Authentication proves possession of keys; authorization proves the action is permitted under delegation and issuer policy.

What evidence should settlement carry?

References to wallet ID, policy version, delegation ID, and proof nonce—not free-text logs.

What fails if canonicalisation of the signed payload is wrong?

Partial signing attacks: the agent signs one view of the transaction while the network processes another.