Both, but identity has to carry more of the load. Generative AI changes the quality of email content, yet the real defence is verifying who is making the request, whether the channel is expected, and whether the action matches policy. That makes email security, user verification, and approval workflows part of one control plane.
Why this is not just an email problem
Generative AI can make malicious or mistaken email look more convincing, but the control question is still the same: who is allowed to request action, through which channel, and under what policy. If your defence stops at spam filters or content review, you can miss the real failure mode, which is an authorised-looking message driving an unauthorised action. That is why the stronger answer is identity-led, with email controls supporting it.
In practice, the distinction matters because email is only the delivery path. The security decision sits at the point of approval, payment, data release, password reset, vendor change, or workflow override. If those actions are not tied to verified identity and expected context, generative AI simply makes social engineering scale and adapt faster. For a broader control model, Identity Security Programme Guide is useful because it treats identity, access and governance as one operating model rather than separate tools.
The same logic is why email security teams and identity teams need shared signals. Email authentication can tell you whether a sender domain passed technical checks, but it cannot by itself confirm whether the request matches policy, role, device, timing or approval path. Identity controls add those checks, while the mail stack contributes filtering, detection and user awareness. That combined model is stronger than treating generative AI as only a content issue or only an access issue.
Where the control plane should sit
The most reliable design is to place identity, approval and verification controls around the action, not around the message. That means unusual payment instructions, MFA reset requests, account recovery, beneficiary changes, mailbox delegation, and sensitive file sharing should all be validated through a separate trust path, not simply by replying to the email thread. NHI Lifecycle Management Guide supports this perspective by showing how ownership, visibility, rotation and offboarding reduce the chance that a stale or ungoverned credential becomes the easiest route into a workflow.
Generative AI also raises the value of channel expectation. If a request arrives by email but the business process normally requires a ticket, portal submission, callback, or dual approval, the mismatch itself is a control signal. Strong organisations encode that expectation into their workflows so that a polished message cannot override process. The security question is not whether the message looks right, but whether the route to action is one the organisation actually recognises.
That is where verification and authorisation converge. A human approver, a service desk agent, and an automated workflow all need the same policy logic: recognise the requester, confirm the channel, and compare the request to permitted action. If the request crosses a boundary such as finance, privileged access, or external communications, identity proofing and step-up approval should be mandatory. For a standards-oriented view of secure identity verification, NIST SP 800-63 Digital Identity Guidelines remains the clearest external reference for assurance and authenticators.
What organisations should optimise for
Organisations should optimise for resilient decisioning, not perfect detection. AI-generated email will keep improving, so the better question is whether a convincing message can actually move money, change access, or disclose data without a second control path. That pushes teams toward verified requests, least privilege on approvals, strong step-up checks for sensitive actions, and logging that makes every exception reviewable.
Because the risk spans both email and identity, the most effective programmes bring those owners together around a shared control objective: reduce unauthorised action, not just suspicious content. The email team should tune for malicious delivery and impersonation, while the identity team should tune for request legitimacy, session risk, privilege boundaries, and approval integrity. For AI-specific governance on top of that, the NIST AI 600-1 GenAI Profile is a strong fit because it frames GenAI risk management, provenance and testing as part of operational governance rather than as an isolated messaging problem.
Risk and Threat Considerations
Generative AI increases the quality and volume of persuasive email, which raises the chance of business email compromise, fraudulent approvals, and account recovery abuse. The main danger is not that the message escapes a filter, but that it reaches a control point where staff trust the appearance of legitimacy more than the underlying identity and workflow evidence.
Failure mechanism: Attackers or internal misuse exploit the gap between message authenticity and action authenticity, then use the trusted channel to trigger approvals, resets, or disclosures that were never properly re-verified.
Impact: Organisations can lose money, expose data, weaken access controls, and create repeatable paths for privilege abuse even when the email itself looked plausible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST AI 600-1, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Level | This question hinges on verifying requester identity before approving sensitive actions. |
| Recommendation — Require the appropriate assurance level before allowing high-impact requests or recovery actions. | ||
| NIST AI 600-1 | GENAI — Generative Artificial Intelligence Profile | GenAI changes message quality and provenance risk in the exact scenario being asked about. |
| Recommendation — Apply GenAI governance and provenance controls to requests that may trigger business action. | ||
| NIST Zero Trust (SP 800-207) | Never trust, always verify — Zero Trust principle | The answer depends on verifying the requester and channel before action is granted. |
| Recommendation — Verify identity and context before allowing any sensitive request to become an approved action. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Human approvers and staff must be authenticated before they can approve sensitive requests. |
| IA-5 — Authenticator Management | Credential and authenticator lifecycle controls matter when email is used to trigger resets or approvals. | |
| Recommendation — Authenticate approvers strongly before letting them act on email-driven requests. Protect and manage authenticators so reset or recovery requests cannot bypass policy. | ||
Practitioner Guidance
What to prioritise: Put the strongest control on high-impact actions first, especially payments, access changes, mailbox delegation, and recovery requests. Those are the places where a convincing email can do the most damage if identity and process checks are weak.
Decision rule: If the request can change money, access, or data, do not trust email alone. Require a separate verification path, then let email act only as a trigger for review, not as proof of authority.
What good looks like: The organisation can show that sensitive actions are approved through expected channels, with identity evidence, policy checks, and audit trails that survive a post-incident review.
Practitioner takeaway: Generative AI makes email more believable, but it does not make it authoritative; the durable defence is to bind every meaningful action to verified identity, expected process, and reviewable approval.
Related resources from NHI Mgmt Group
- Should organisations treat shadow AI as a security risk or an innovation issue?
- When should security teams treat AI design tooling as an identity governance issue?
- What do organisations get wrong when they treat BEC as only an email security issue?
- What breaks when organisations treat non-human identity risk as a secondary security issue?