Who is accountable when an AI agent or mobile app enables authorized fraud?

Why This Matters for Security Teams

When an AI agent or mobile app is permitted to act on behalf of a user, the fraud risk is not created by authentication alone. The hard question is whether the organisation defined the delegation boundary, approval logic, and monitoring needed to keep that authority constrained. Current guidance suggests treating the agent or app as a governed workload, not just a login event, especially when it can move money, change payee details, or trigger account actions.

That distinction matters because authorised fraud often looks legitimate at the point of execution. A valid token, a real user session, or a trusted device does not prove that the action was intended, proportionate, or properly supervised. In practice, the weak point is usually not the credential, but the control design around delegated access. NHI Management Group’s coverage of the OWASP NHI Top 10 and the NIST AI Risk Management Framework both point to the same operational truth: identity is only one control plane, while policy, oversight, and evidence determine accountability.

In practice, many security teams encounter authorised fraud only after a valid delegation has already been abused, rather than through intentional control testing.

How It Works in Practice

Accountability should follow the organisation that created the trust relationship and the action boundary. For a mobile app, that means the business owner, security owner, and product team that approved the delegated functions. For an AI agent, it also includes the team that defined what the agent may decide, which tools it may call, and which transactions require human confirmation. That is why modern guidance increasingly treats agentic systems as policy-governed workloads, not static users.

Operationally, the strongest pattern is to combine least privilege with runtime controls. The app or agent should receive only the minimum scope needed for the task, ideally as short-lived credentials or tokens that expire quickly. For higher-risk actions, use step-up approval, transaction signing, or human-in-the-loop review. Policy should be evaluated at request time, using context such as transaction amount, destination, device posture, behavioural anomaly, and prior approvals. Frameworks like the OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework are useful because they emphasise runtime governance, not just initial authentication.

For fraud investigations, evidence matters as much as prevention. Teams should log who authorised the delegation, what limits were set, what the workload attempted, what policy allowed it, and whether a human approved the final action. NHIMG’s analysis of the LLMjacking threat vector shows why this cannot be treated as a theoretical issue: once credentials or delegated access are misused, abuse can unfold quickly and look legitimate in logs.

• Define the accountable business owner for every delegated action path.
• Use short-lived credentials and revoke them when the task ends.
• Require step-up approval for high-value or irreversible transactions.
• Record policy decisions, approvals, and exception handling for audit.

These controls tend to break down in high-volume consumer apps with fragmented approval flows because risk decisions are spread across channels and no single owner can prove end-to-end delegation oversight.

Common Variations and Edge Cases

Tighter delegation controls often increase friction, so organisations must balance fraud reduction against customer experience, operational latency, and support burden. That tradeoff becomes sharper when the action is technically authorised but commercially disputed, such as a payment initiated by an agent acting within a user-approved limit.

There is no universal standard for this yet, but current guidance suggests using the same accountability model across channels: if the organisation enabled the action, the organisation owns the control design. A consumer banking app may rely on explicit confirmation for payee changes, while a business workflow may accept policy-based automation with stronger logging and delegated authority records. For AI agents, the bar should be higher because their behaviour is adaptive and can chain tools in ways that are not fully predictable. That is why the practical question is not “was the login valid?” but “was the delegated authority properly bounded, supervised, and auditable?”

NHIMG’s research on the IOS app secrets leakage report and the State of Secrets in AppSec also reinforce a related edge case: when mobile clients or backend services mishandle secrets, organisations lose the ability to prove whether an action was genuinely authorised or simply technically enabled.

One useful rule is to separate “permission to act” from “permission to complete.” If the app or agent can start a high-risk flow, a second control should decide whether it may finish it. That distinction is especially important where consumer protection law, payment regulations, or internal fraud policy require stronger evidence than a normal access log can provide.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• When do AI agent credentials create more risk than they reduce?