Accountability usually sits with the organisation’s security and risk leadership, because social engineering is a governance problem as much as a technical one. Teams should define control ownership across awareness, identity verification, email security, and incident response. Clear reporting paths and response playbooks matter because AI makes impersonation faster, cheaper, and harder to spot.
Why This Matters for Security Teams
AI-generated social engineering shifts the problem from obvious spam to believable, adaptive impersonation. That means accountability cannot stop at the last employee who clicked or replied. Security and risk leadership must own the controls that reduce exposure before a message reaches a human, including identity verification, secure reporting paths, email filtering, and response coordination. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and ENISA Threat Landscape consistently treats social engineering as a governance and resilience issue, not just an end-user mistake.
NHI Management Group has documented how social engineering cascades into identity compromise in incidents such as the MGM Resorts Breach 2023 — Scattered Spider and the Storm-2949 Azure Breach, where human deception became an identity and access failure. In practice, many security teams encounter the real control gap only after a forged message has already led to credential capture, account takeover, or fraudulent approvals.
How It Works in Practice
Accountability is usually shared, but it should be explicit. Security leadership owns the control environment, business leaders own process discipline, and managers own local enforcement of verification steps. The employee is part of the control chain, but not the sole control. A mature program maps who approves what, who verifies a request, who can override a control, and who is notified when a message looks suspicious.
Practically, strong programs combine technical and procedural controls. That includes phishing-resistant authentication, policy-based email security, out-of-band verification for payment or account changes, and rapid reporting channels that route suspicious messages to SOC or help desk workflows. NIST’s identity guidance in NIST SP 800-63 Digital Identity Guidelines supports stronger identity proofing and authenticator assurance, while incident handling guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces logging, response, and access restrictions.
That is where reporting matters. If employees are trained to forward suspicious messages, the security team can contain patterns, tune detections, and warn others before the same lure spreads. NHIMG’s Co-op Group DragonForce Breach — Scattered Spider illustrates how a single successful deception can become an enterprise incident when identity verification is weak and response paths are slow. These controls tend to break down in decentralised organisations where approval chains are informal and high-trust business units bypass security review.
Common Variations and Edge Cases
Tighter verification often increases friction, requiring organisations to balance user convenience against fraud resistance. That tradeoff becomes visible in high-speed functions such as finance, HR, executive support, and IT service desks, where attackers exploit urgency, hierarchy, or routine exceptions. Best practice is evolving here: there is no universal standard for exactly which messages require step-up verification, but current guidance suggests that payment instructions, password resets, MFA resets, and vendor banking changes should always be treated as high-risk.
Edge cases also matter. If a deepfake voice call or AI-written message is paired with a compromised account, accountability expands beyond email security into identity lifecycle management, privileged access, and incident response. NHIMG’s reporting on the Caesars Entertainment Breach 2023 — Scattered Spider and MailChimp Breach shows how deception often lands where identity controls are weakest, not where the message first arrived. The practical rule is simple: if the message can change access, move money, or expose secrets, ownership must extend beyond the employee to the control owner, process owner, and incident commander.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | AI social engineering exploits weak identity and access decisions. |
| NIST SP 800-63 | AAL2 | Phishing-resistant identity assurance reduces message-driven account takeover. |
| OWASP Non-Human Identity Top 10 | NHI-07 | Credential theft and impersonation often begin with deceptive messages. |
| OWASP Agentic AI Top 10 | LLM-02 | AI-generated messages are an output misuse and impersonation risk. |
| NIST AI RMF | Accountability for AI-enabled deception fits AI governance and risk management. |
Add policy checks and human verification before automated or high-impact responses.
Related resources from NHI Mgmt Group
- How should security teams defend extended workforce onboarding and account recovery against AI-driven social engineering?
- Who is accountable for data exposure risk when employees use AI browsers for work?
- How should security teams detect AI-generated social engineering that looks legitimate?
- Who is accountable when employees submit credentials to an AI-generated phishing site?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
