Email security, IAM, fraud, and business process owners all share accountability because the attack crosses technical and organisational boundaries. The decisive control is whether sensitive actions require identity verification outside the inbox, not whether one team owns the entire problem.
Why This Matters for Security Teams
AI-driven email fraud is not just a mail gateway problem. It is an identity, workflow, and fraud problem that can begin with a convincing message and end with an approved payment, password reset, or payroll diversion. NIST’s NIST Cybersecurity Framework 2.0 makes the boundary issue clear: detection matters, but governance and response have to span multiple functions. For agencies, the operational risk is that attackers increasingly exploit trust in the inbox to bypass controls that were never designed to verify intent outside email.
The accountability question matters because no single team sees the whole chain. Email security can block phishing, IAM can protect accounts, fraud teams can review anomalies, and business owners can approve transactions, but AI-driven fraud crosses all of them. That is why NHI Management Group treats this as a control-orchestration issue, not a silo ownership debate. Where sensitive actions depend on email alone, attackers can use language models to scale impersonation, adapt tone, and sustain back-and-forth until someone authorizes the wrong change. In practice, many security teams encounter the failure only after a fraudulent request has already moved through a normal business workflow rather than through intentional control testing.
How It Works in Practice
Accountability should be assigned by control point, not by message channel. The team that owns the inbox should be responsible for email-layer protection, the IAM team for identity verification, the fraud or finance control owner for payment and beneficiary changes, and the business process owner for step-up approvals and exception handling. The critical design choice is to require verification outside the email thread when the request is high-risk. That means out-of-band confirmation, stronger authentication for sensitive actions, and policy checks that inspect context rather than trusting message content.
For agencies, the practical model looks like this:
- Email security flags impersonation, spoofing, and suspicious routing patterns.
- IAM enforces step-up authentication before account changes, password resets, or MFA re-enrollment.
- Fraud controls require second-channel verification for payment changes, vendor updates, and bank detail edits.
- Business owners approve only after the request is validated against a known process and not just a familiar sender.
That model is consistent with broader identity guidance and with NHIMG research showing how quickly exposed credentials are abused. The DeepSeek breach illustrates the scale at which sensitive data and credentials can become exposed, while the State of Secrets in AppSec highlights how weak practices and fragmented ownership persist even in mature programs. When attackers can pivot from a convincing message to a real credential or workflow approval, the control has already moved beyond email security alone. These controls tend to break down in agencies with decentralized approval chains and no mandatory out-of-band verification because attackers simply route around the weakest approver.
Common Variations and Edge Cases
Tighter approval controls often increase processing time and user friction, so agencies have to balance speed against the cost of fraud. Best practice is evolving, but there is no universal standard that says every email-initiated request needs the same level of verification. High-risk actions should get the strongest review, while low-risk internal coordination can remain lightweight. The important point is that the control should scale with impact, not with how persuasive the message sounds.
There are also edge cases where ownership becomes blurry. Shared mailboxes, delegated authority, emergency procurement, and executive assistants can all create legitimate exceptions that attackers try to mimic. In those cases, accountability should sit with the owner of the business risk, supported by the security team that defines the verification rule. Agencies should document who can override a hold, what evidence is required, and how exceptions are reviewed after the fact. Without that clarity, teams tend to assume another group handled verification, and the fraud lands in the gap between policy and execution.
For mature programs, the best operating pattern is a joint control map: email team for detection, IAM for identity assurance, fraud owner for financial validation, and process owner for final approval. The decision that matters most is whether the transaction can be completed without proving identity somewhere other than the inbox.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-03 | Risk ownership must span email, IAM, fraud, and business workflows. |
| NIST AI RMF | AI-driven fraud requires governance across people, process, and technology. | |
| OWASP Agentic AI Top 10 | AI systems can adapt language and chaining to bypass inbox-based trust. |
Assign named owners for each fraud control and review them as part of enterprise risk governance.
