How should security teams handle accountability for unauthorised agent purchases?

Who should be treated as accountable when an agent buys without approval?

Accountability should follow the control chain, not just the purchase event. If a human delegated authority, the organisation needs to know who granted it, what the agent was allowed to do, and whether the merchant accepted the transaction under those conditions. That makes the question answerable across security, procurement, finance, and legal review instead of being reduced to “the agent did it.”

For ownership and accountability, the useful test is whether the organisation can name the responsible owner at each step of the chain. In practice, that means the delegation source, the operating team, and the business approver should all be identifiable in the record, even if liability later lands elsewhere.

Where the purchase was made by an agent acting on behalf of a user, the accountability question is really about delegated authority and the boundary of that authority. That is why teams should treat the purchase trail as a control evidence problem, not only a dispute-resolution problem, and keep the record complete enough to show whether the action stayed within the intended scope.

What evidence makes an unauthorised purchase traceable?

The minimum useful evidence is a continuous audit chain from delegation to action to acceptance. If any link is missing, the team may still suspect abuse, but it cannot prove whether the event was a policy failure, a stolen credential, an overbroad permission, or an accepted but unintended action.

For agentic systems, a clear example of that chain is the AI Agent Observability, Audit and Incident Response Guide, which focuses on attributing agent actions and preserving signals that support incident handling. The same evidence discipline applies here: log who delegated, what policy or approval gate was in force, what the agent requested, what the merchant accepted, and whether any exception path was used.

Teams should also preserve the commercial artefacts that matter to chargeback and governance decisions, not just the technical logs. Order IDs, payment references, merchant response codes, timestamps, and any user confirmation trail can make the difference between a recoverable exception and an unresolvable dispute.

For identity-enabled agent purchases, the Agentic Commerce Identity Guide is useful because it frames agent payments around mandates and verifiable intent rather than raw tool access. That distinction matters when the organisation needs to show whether the purchase reflected an authorised mandate or an overreach.

How should teams structure governance so disputes do not become speculation?

Governance should separate permission to act from permission to spend. An agent can be allowed to complete a workflow without being allowed to create open-ended financial exposure, and the policy should make that difference visible. This is where delegated authority, approval thresholds, and post-action review need to be explicit enough that finance and security can reconcile them later.

The strongest operational pattern is to pair a bounded mandate with searchable evidence. For AI agents, AI Agent Authorisation Guide is directly relevant because it emphasises task-scoped access, per-action decisions, and human approval gates. Those are the controls that reduce ambiguity when an agent purchase is challenged.

Teams should also define an exception path for disputed purchases before the first incident occurs. If the review process depends on ad hoc judgment, accountability becomes inconsistent across departments; if it depends on recorded authority and policy state, the organisation can make repeatable decisions about refund requests, merchant claims, user reimbursement, and control changes.

Risk and Threat Considerations

Unauthorised agent purchases create both control risk and abuse risk. The main exposure is that a buyer, approver, or merchant may later rely on incomplete logs and assume the transaction was valid because a system initiated it, when in fact the agent exceeded its mandate or used an inherited approval path.

Failure mechanism: Weak delegation records, overbroad permissions, or poor transaction logging break the chain between intent and execution, so the organisation cannot distinguish legitimate automation from accidental overspend or malicious use of an agent account.

Impact: The team loses the ability to support chargebacks, assign accountability, or prove that a purchase was outside policy, which can turn a controllable control failure into a financial loss and governance dispute.

Practitioner Guidance

What to verify: Confirm that every purchase path has a recorded principal, a recorded mandate, a policy decision or approval outcome, and a merchant acceptance record. If any one of those is missing, treat the case as an investigation, not as a settled liability decision.

Decision rule: If the agent can create financial commitment, require the same standard of traceability you would expect for a human approver, including who authorised the scope, who owns the agent, and what controls can prove the action was within mandate.

What good looks like: A reviewer can reconstruct the transaction without relying on memory or screenshots, and can tell whether the issue was unauthorised use, policy drift, or simply an authorised but disputed purchase.

Practitioner takeaway: Do not wait for legal clarity to define accountability. Build the evidence chain now so the organisation can make a defensible judgement even when liability, reimbursement, and merchant dispute rules are still evolving.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?