The main failure is that traditional approval models assume a human remains in the loop for each material action. An agent can complete transactions faster than review cycles and may reuse delegated rights across multiple steps. That creates a standing authority problem unless scope, expiry and traceability are enforced.
Why spending authority breaks the old approval model
When an AI system can spend on behalf of a user, the key break is not payment mechanics alone. It is the collapse of a control model built around a person approving each meaningful action. If the system can chain steps, reuse delegated rights, or act faster than review, the organisation must govern the authority itself, not just the transaction outcome.
That shifts the question from “did a human click approve?” to “what can this delegated actor do, for how long, and under which conditions?” Once spending is possible, the dangerous state is standing authority with unclear boundaries, because the agent may keep operating after the original intent, context, or business need has changed.
In practice, this is why RFC 8693: OAuth 2.0 Token Exchange matters for on-behalf-of flows: delegation has to be represented explicitly, not implied by a broad credential that never expires.
What has to be controlled: scope, expiry, and traceability
The subject is not “can an AI pay?” but “what authority is granted when it pays?” Good control design limits the spending surface in three places. Scope defines what can be bought, from whom, and up to what threshold. Expiry limits how long the authority survives. Traceability shows which user intent, policy, or prior approval justified the action.
Those controls should be attached to the delegated right, not left as application memory or informal process. If the agent can move across tools, vendors, or workflow steps, the authority must stay bounded at every hop. Otherwise the system quietly turns a one-time instruction into persistent access.
That is why identity and delegation design matters as much as payment logic. NHIMG’s Agentic AI Identity Guide is directly relevant here because it treats agent identity, delegation, registration, and retirement as the control plane for on-behalf-of action. Relatedly, the Human vs Non-Human Identity guide helps frame why shared or ambiguous authority becomes unsafe once machine action is allowed to stand in for user intent.
For teams that implement this through secrets and authentication rather than explicit delegation, NHIMG’s NHI Authentication Guide is the practical companion: strong authentication alone is not enough if the authenticated actor still carries excessive, long-lived spending rights.
Where the real failure shows up in operations
The operational failure usually appears as drift between intent and execution. A user authorises a narrow task, but the agent uses the same delegated path to continue buying, renewing, upgrading, or retrying without fresh review. That creates liability in three directions: financial exposure, policy non-compliance, and weak attribution when teams later need to prove why a purchase occurred.
This is also where overbroad trust in automation becomes visible. If exception handling, retries, or vendor fallbacks are treated as harmless implementation details, the agent can spend in ways the human never consciously approved. The result is often not a dramatic breach, but a slow accumulation of unauthorised or poorly governed spend.
For agent-specific governance, the Agentic AI Compliance Guide is useful because it connects audit evidence, accountability, and regulatory expectations to the actual delegated action path. If the system can spend money, auditability is not optional metadata, it is part of the control.
For a complementary external reference on the same mechanism, RFC 8693 provides the standards basis for token exchange and delegated authority, which is the right conceptual model when an agent acts on a user’s behalf.
Risk and Threat Considerations
The main risk is uncontrolled delegation, where a granted capability outlives the user’s intent or is reused across more actions than the user expected. That can produce unauthorised spending, privilege creep, and poor accountability even when no one “breaks in” in the classic sense.
Failure mechanism: The agent inherits a broad or reusable authority token, then chains multiple actions, retries failed transactions, or reuses the same delegated rights across contexts where fresh human approval was expected.
Impact: Financial loss, policy violations, disputed transactions, and a weak forensic trail that makes it hard to show which action was truly authorised and which was merely possible.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent spending on behalf of users is a delegated authority and privilege problem. |
| Recommendation — Bind agent spending to least-privilege delegated access and review every privilege path. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Spending authority depends on how the agent authenticates and represents delegated access. |
| NHI-05 — Overprivileged NHI | An agent that can spend broadly is an overprivileged non-human actor. | |
| NHI-07 — Long-Lived Secrets | Standing spending authority often persists because the backing secret or token lasts too long. | |
| Recommendation — Use phishing-resistant, scoped authentication and avoid reusable broad credentials. Reduce agent entitlements to the minimum actions and merchants required. Shorten secret and token lifetimes and rotate any credential used for spend. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | An AI spending on behalf of users is a non-organizational actor needing controlled authentication. |
| AC-6 — Least Privilege | Spending authority must be limited to the smallest viable set of transactions. | |
| AU-2 — Event Logging | Spending delegation requires records that show who authorized what and when. | |
| Recommendation — Authenticate delegated non-organizational actors with bounded, verifiable credentials. Restrict each agent to the minimum spending actions required for its task. Log delegated spend decisions, retries, and approvals with sufficient context. | ||
Practitioner Guidance
What to verify: Confirm that every spending-capable path has a hard scope, a short expiry, and an audit record that ties the action to a specific user intent or policy basis. If you cannot answer who delegated what, for how long, and with what maximum spend, the control is not yet real.
Decision rule: If the AI can renew, retry, or chain transactions without re-authentication or re-approval, treat it as standing authority and reduce the privilege before expanding the workflow.
Practitioner takeaway: The safe design goal is not to block all autonomous spending, but to make delegated spend narrowly bounded, time-limited, and attributable at the point of action.