A signature proves that a key signed a constrained object, not that the human intended the exact purchase or that the agent was safe to trust. If the agent runtime can obtain signatures for broad or ambiguous requests, the organisation still needs policy, scoping and an external enforcement point to keep the risk bounded.
Why a signed mandate still leaves payment risk
A signed mandate proves provenance, not safety. It shows that a key approved a bounded object, but it does not prove the human wanted that exact purchase, that the request was narrow enough, or that the agent runtime was prevented from reusing the same approval for a broader action.
That distinction matters most when the signing flow is treated as a substitute for policy. If the agent can obtain signatures for vague, overbroad, or recycled requests, the signature becomes an artefact of authorisation plumbing rather than a control that meaningfully constrains spend.
In payment terms, the risk is not just forged intent, it is delegated intent drifting beyond the user’s actual authority. A mandate can be technically valid and still permit the wrong amount, the wrong merchant, the wrong timing, or an unintended recurrence if the surrounding policy is weak.
What has to be controlled around the mandate
The control problem is broader than the cryptographic signature. You need a policy layer that defines what the agent may request, a scoping layer that limits the object being signed, and an enforcement point that checks the request against current context before any payment action is released.
That means the mandate should be treated as one input to decisioning, not the decision itself. For autonomous agents, the important question is whether the signing event is tied to an exact, reviewable action, or whether it can be reused as a generic approval token for future actions.
Strong designs keep the purchase object narrow and auditable. The mandate should bind amount, beneficiary, purpose, time window, and any recurrence rules tightly enough that downstream execution cannot quietly expand the scope.
For agentic commerce, that is why a broader identity and policy model matters. The Agentic Commerce Identity Guide is useful because it frames mandates as part of the identity and delegation model, not as a standalone trust primitive.
Why trust boundaries still matter after the signature
A signed mandate does not prevent an autonomous agent from being tricked, over-prompted, or over-scoped before the signature is created. If the agent can be induced to ask for the wrong approval, the damage happens before any cryptographic check is applied.
The same is true when the system that brokers approval is too close to the execution path. A separate enforcement point is needed so the component that understands policy is not the same component that is trying to complete the payment and benefit from approval.
This is especially important where the agent may act across services, merchants, or channels. In that environment, the issue is not whether a signature exists, but whether the runtime can turn a legitimate approval into a broader payment path than the user expected.
For practitioners trying to evaluate those boundaries, the AI Agent Authorisation Guide is a good companion because it separates delegated authority, per-action decisions, and human approval into operational controls.
The Zero Trust for AI Agents guide also fits this problem well, because it treats the agent, the principal, and the request as separate things that all need verification before trust is extended.
Risk and Threat Considerations
Signed mandates can create false confidence if teams assume cryptographic approval equals controlled spend. The real exposure is mandate abuse, where a valid signature is used to legitimise a request that was too broad, too vague, or too easy for an agent to obtain again.
Failure mechanism: The agent runtime or its surrounding workflow can request signatures for ambiguous actions, cache approvals, or widen the transaction context after approval, so the cryptographic proof no longer matches the human’s original intent.
Impact: The organisation can still suffer unauthorised or excessive payments, replayed approvals, recurrence outside expectation, and weak attribution when a payment dispute or incident must be investigated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Signed mandates can still be abused when agent authority exceeds intent. |
| Recommendation — Enforce per-action authorization so agents cannot expand a signed mandate into broader payment actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Payment mandates need tightly bounded agent privilege to limit payment scope. |
| AU-2 — Event Logging | Payment mandate disputes require auditable proof of what was approved and executed. | |
| IA-5 — Authenticator Management | Mandates rely on controlled signing material and its lifecycle. | |
| Recommendation — Restrict agent permissions to the minimum needed for the approved transaction. Log mandate creation, scope, approval, and execution to support traceability. Rotate and protect signing credentials so approval capability cannot be reused improperly. | ||
| NIST Zero Trust (SP 800-207) | AC-3 — Access Enforcement | A separate enforcement point is needed so approval and execution are not the same trust step. |
| Recommendation — Place policy enforcement outside the agent so each payment is checked before release. | ||
Practitioner Guidance
What to verify: Check that the signed object is the exact transaction object the runtime will execute, not a general intent statement or a reusable approval blob. If the signed content does not bind the amount, recipient, and use case tightly, it is not a sufficient control for autonomous payment execution.
Decision rule: If the agent can request approval without a user seeing the concrete payment consequences, require an external policy check or human confirmation before release. Treat the signature as evidence of consent to a constrained action, not as evidence that the action is safe.
What good looks like: Good designs make every payment decision externally enforceable, narrowly scoped, and auditable. The best signal is that the agent cannot convert a broadly signed request into a materially different payment without failing policy.
Practitioner takeaway: Signed mandates reduce ambiguity only when the approval is tightly bound to the exact payment and enforced outside the agent runtime; without that, they document trust but do not bound risk.