How should security teams respond to AI-assisted phishing and social engineering?

Treat AI-assisted phishing as a scale and quality problem, not just a messaging problem. Tighten authentication at the point of approval, train users on high-risk workflows such as payment and recovery, and monitor sessions for abnormal behaviour after credentials are entered. The goal is to make the attacker’s next step harder even if the lure succeeds.

Why This Matters for Security Teams

AI-assisted phishing raises the quality and volume of deception at the same time, which means traditional user-awareness messaging is no longer enough on its own. Attackers can generate convincing lures, mirror internal tone, and adapt in real time once a target engages. That shifts the control objective from “spot the bad email” to “make fraudulent approval, recovery, or credential entry harder to complete.” Guidance in the NIST Cybersecurity Framework 2.0 supports this layered approach: reduce likelihood, limit blast radius, and detect abnormal activity early. NHIMG research on the State of Non-Human Identity Security shows how often organisations still lack visibility and confidence around identity-driven risk, which is relevant because phishing success increasingly depends on identity compromise rather than malware delivery. In practice, many security teams encounter the real impact only after an approval, reset, or session handoff has already been abused, rather than through intentional detection of the lure itself.

How It Works in Practice

The most effective response is to harden the steps that follow a successful lure. If an attacker convinces someone to click, the next objective is usually credential capture, session hijack, or approval abuse. Security teams should therefore focus on authentication strength, transaction verification, and post-login monitoring rather than email filtering alone.

• Use phishing-resistant authentication for high-risk workflows, especially finance, admin recovery, and identity resets.
• Require step-up approval or out-of-band verification for payment changes, MFA resets, and privilege grants.
• Monitor for abnormal session behaviour after login, including unusual geolocation, device changes, impossible travel, and rapid tool use.
• Limit the value of stolen credentials with short-lived sessions, conditional access, and revocation triggers.

This is where identity guidance becomes practical. The NIST SP 800-63 Digital Identity Guidelines help teams separate low-assurance from high-assurance authentication events, while NHIMG coverage of the DeepSeek breach is a reminder that downstream access and trust decisions matter once initial access is lost. The operational goal is to make a stolen password or clicked lure insufficient to complete a meaningful action. These controls tend to break down in high-friction environments where business units bypass verification steps for speed, because attackers exploit the shortest path to approval rather than the strongest technical control.

Common Variations and Edge Cases

Tighter approval controls often increase friction, requiring organisations to balance user convenience against the risk of delayed operations. That tradeoff is especially visible in help desk resets, executive inboxes, and vendor payment flows, where a single exception can undo a well-designed policy. Best practice is evolving, but current guidance suggests that high-risk workflows deserve separate treatment rather than one-size-fits-all phishing training.

Some edge cases need different handling:

• Executive impersonation and deepfake voice scams often succeed outside email, so callback verification and pre-agreed code words matter.
• Vendor and contractor accounts may be the weakest link if shared inboxes or shared approval paths are still allowed.
• AI-generated phishing against internal chat tools can bypass email security entirely, so alerting must extend to collaboration platforms.
• For highly privileged users, monitoring should focus on behaviour after authentication, not just login success.

The right response is not to treat every employee the same, but to align controls with the business action being protected. Where organisations still rely on informal approval norms, the attacker’s advantage grows because the social engineering target is the process, not the person.

Related resources from NHI Mgmt Group

• How should security teams defend against AI-generated phishing at enterprise scale?
• What steps should security teams take to prevent Shadow AI risks?
• How should security teams respond to faster AI-assisted vulnerability discovery?
• How should security teams stop AI-powered social engineering from leading to privileged access?