Who is accountable when an AI agent changes prices or processes a refund incorrectly?

Why This Matters for Security Teams

When an AI agent can change prices or trigger refunds, the accountability question is not academic. The real issue is that an autonomous system has executed a business action that may look like a human decision in the ledger, the CRM, or the finance system. That means the control objective is not just access restriction, but provable ownership, runtime authorisation, and a defensible audit trail. Current guidance from NIST AI Risk Management Framework and OWASP Agentic AI Top 10 points to governance, traceability, and misuse resistance as baseline expectations, not optional extras. NHIMG research shows the scale of the problem: 80% of organisations report their AI agents have already performed actions beyond intended scope, and only 52% can track and audit the data those agents access, according to AI Agents: The New Attack Surface report by SailPoint. In practice, many security teams encounter accountability failures only after a refund dispute, pricing incident, or compliance review has already exposed the missing owner.

How It Works in Practice

The operational answer starts with assigning a named human owner to every agent workflow, then binding that workflow to workload identity and time-bound privilege. An AI agent should not inherit broad human permissions or a static service account with standing access. Instead, it should receive just-in-time credentials, short-lived secrets, and request-scoped authorisation for a specific task such as “issue refund up to $50” or “apply promotional discount within policy bounds.” That is the practical difference between role-based access control and intent-based authorisation: the first assumes a stable job function, while the second evaluates what the agent is trying to do right now. A defensible pattern usually includes:

• Workload identity for the agent, so the system can prove what the agent is and which orchestration path invoked it.
• Policy-as-code checks at the moment of action, using current context such as amount, customer status, region, and approval threshold.
• Ephemeral secrets with automatic revocation after the task completes.
• Immutable logging that records the prompt, tool call, policy decision, output, and human owner.

This aligns with the control logic described in the CSA MAESTRO agentic AI threat modeling framework and the deployment patterns discussed in OWASP NHI Top 10. It also reflects the identity and lifecycle discipline covered in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. These controls tend to break down when an agent is allowed to chain tools across finance, support, and CRM systems with one persistent token, because the blast radius expands faster than the logs can be correlated.

Common Variations and Edge Cases

Tighter approval gates often increase friction, so organisations have to balance speed against control without pretending there is a universal standard for every workflow. High-value refunds, live pricing changes, and regulated customer decisions usually need stronger human-in-the-loop approval than low-risk catalogue updates. By contrast, many teams can safely automate only the recommendation step while keeping the final price change or refund issuance under explicit human approval. That is especially important where PCI-DSS, privacy obligations, or customer financial impact are involved. Two edge cases matter. First, if the agent acts through a shared integration account, attribution becomes weak even if the business process looks automated. Second, if the agent is orchestrated by multiple models or toolchains, the audit trail must show which component made the final decision, not just which UI initiated the request. This is where best practice is evolving, and NIST AI Risk Management Framework remains useful because it frames accountability as a governance control, not merely an engineering detail. For threat modelling, MITRE ATLAS adversarial AI threat matrix helps teams think about abuse paths that combine prompt manipulation, tool misuse, and privilege escalation. The practical lesson is that accountability fails fastest where autonomous agents are given standing access, weak ownership, and incomplete evidence.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who is accountable when an AI agent uses delegated access incorrectly?
• Who is accountable when a customer-facing AI gives harmful or off-topic advice?
• What makes agentic AI an NHI governance issue?