Standardize the Binding, Not Just the Cap
Agent-payment proposals are learning to standardize what’s present on the wire, and some now sign it. The enterprise question is what else has to hold before a signed mandate is actually enforceable.
Enterprise Agent Architecture adds a fifth domain to the classical four, and that domain has four layers: Workforce, Capability, Control Plane, and Governance. Agent-payment proposals in this space have largely focused on the Capability layer — what a "payment required" state should carry on the wire: network, asset, amount cap, recipient, expiry, idempotency key, proof-header shape, denial reason. That list is the right instinct. Google's AP2 already goes further than a bare field list: it uses signed mandates as evidence of the user's original instruction, which is exactly the kind of binding this note argues for. The question here is what still has to be true even once a proposal signs its mandates — because a signed reference, on its own, does not finish the job.
Present Is Not Provable, and Signed Is Not Yet Enforced
A wire field standardizes what is present in a transaction. A signature over that field establishes a cryptographic relationship to a signing key — not, on its own, who wrote it. Identifying the issuer additionally requires a trusted binding from that key to an identity, and signing a document is not necessarily the same act as authoring its terms. None of that, by itself, establishes what a downstream system needs: that the mandate's issuer actually had the authority to grant it, that the mandate applies to this agent and this transaction, that it is still valid, and that executing the payment would not exceed whatever budget remains against it.
An intermediary that can substitute both the fields and an unauthenticated reference to them can still produce a package that looks internally consistent. A content-addressed reference to immutable content proves the content wasn't altered after the reference was made — it does not, by itself, prove who was authorized to make that reference, or that the reference is the one this transaction should be checked against.
Four Responsibilities, Four Layers
The binding an enterprise actually needs decomposes into four separate responsibilities, and a payment proposal has to account for all four, not just the first:
| EAA layer | Responsibility |
|---|---|
| Workforce | Principal, delegation, mandate, and issuer authority — authenticate the issuer and establish that the issuer actually had the authority to grant it |
| Capability | The payment operation itself and its scope/constraints — the fields (currency/asset, network where relevant, recipient, amount semantics, expiry, transaction or replay scope), covered by an authenticated integrity mechanism |
| Control Plane | Validate the mandate, remaining budget, and freshness/replay conditions before commitment — including, for an aggregate cap, coordinated accounting across concurrent payments against the same mandate |
| Governance | Ratify the policy, assign accountability, and review the retained evidence connecting the actual outcome to the mandate and the enforcement decision that let it through |
Enforcement can physically run inside a payment service or a single gateway process — that's an implementation choice. Its logical role in this model doesn't change: pre-commitment validation against the mandate's remaining budget and freshness is Control Plane work, distinct from the Capability layer that defines what the payment operation itself carries and distinct from the Workforce layer that established the mandate in the first place.
Which Layer Owns Which Proof
Enterprise agent platforms are adding spend limits on agent actions. The platform question is not whether the limit exists. It is which layer owns which piece of the proof above — issuer authority, term binding, pre-commitment enforcement, and post-hoc reconstruction are four different jobs, and a proposal that only names the fields has done the Workforce/Capability paperwork, not the Control Plane and Governance jobs that make it enforceable and auditable.
Standardizing the binding is necessary. It does not make enforcement optional: something in the Control Plane still has to check the mandate and refuse the payment when it doesn't hold, every time, before commitment — the cap does not enforce itself just because its terms are provable.
Source
Google's AP2 announcement, cited above for its use of signed mandates as evidence of user instructions, predates this essay: Announcing Agents to Payments (AP2) Protocol.
About This Series
Michael K. Saleme — Enterprise Agent Architect
A field note applying the Enterprise Agent Architecture layer model to a live standards question: where a spend limit’s authority is bound, and which layer has to prove it.
This page is the canonical version of an essay also published to the Enterprise Agent Architecture newsletter.
Cite the Position Paper
This essay develops the Enterprise Agent Architecture position paper, which is published and citable on Zenodo under CC BY 4.0. Cite the concept DOI — it always resolves to the latest version.
Saleme, M. K. (2026). Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise. Zenodo. https://doi.org/10.5281/zenodo.21105314
BibTeX
@misc{saleme2026eaa,
author = {Saleme, Michael K.},
title = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
year = {2026},
publisher = {Zenodo},
doi = {10.5281/zenodo.21105314},
url = {https://doi.org/10.5281/zenodo.21105314}
}
Michael K. Saleme
Enterprise Agent Architect · Cognitive Thought Engine