AI Deepfake Social Engineering Under the NYDFS AI Letter: Controls for Bank Help Desks and Account Changes

What the letter says and how the attack works

DFS released its industry letter on cybersecurity risks arising from AI on October 16, 2024. DFS states that it does not impose new requirements. It helps regulated institutions meet existing Part 500 obligations in light of AI risks, and DFS describes the combined measures as multiple layers with overlapping protections, so that if one control fails others can prevent or mitigate the impact. As of November 2026, the published Part 500 text reflects the Second Amendment.

The letter calls AI-enabled social engineering one of the most significant threats to the financial services sector. Threat actors use AI to create realistic, interactive audio, video and text, and deliver it by email, telephone, text message, videoconferencing and online postings. The letter notes that deepfakes leading to shared credentials can give access to systems containing nonpublic information, that employees have taken unauthorized actions such as wiring substantial funds to fraudulent accounts, and that deepfakes have been used to mimic appearance or voice to circumvent biometric verification.

For a help desk, the pattern is direct. A caller who sounds like an employee or customer asks for a credential reset, an MFA re-enrollment or a change to contact details. DFS has also issued alerts on social engineering of IT help desk personnel and on vishing campaigns in which attackers impersonate help desks and service providers. The vishing letter recommends training on these tactics and a review of MFA controls, including permissions for MFA enrollment. Federal Reserve Governor Barr noted in April 2025 that a short audio sample can be enough to impersonate a high-value client.

Where runtime enforcement on AI interactions fits

If an AI assistant, agent or tool can trigger a credential reset or a contact detail change, it is another channel an impersonator can try to manipulate. Human-facing checks do not cover it, so the actions it can take need their own limits, and those limits need to hold regardless of how persuasive the input is.

This is where policy enforcement in the execution path applies. Trussed enforces policy on individual AI interactions and tool calls at runtime, not in review after the fact. The available outcomes are allow, redact, block, rate limit and escalate for human approval. In these workflows, that could mean blocking a contact detail change tool call unless approval is present, escalating an MFA re-enrollment request to a human approver, redacting nonpublic information from a model interaction, or rate limiting repeated reset attempts.

The boundaries matter. Trussed does not prove who is on the call, and it does not replace identity proofing, authentication or fraud detection. Those remain separate controls that must work first. Enforcement on the AI path is an additional layer consistent with the overlapping-protections approach in the letter. Its scope is individual interactions and tool calls, so it is not a substitute for case-level approval records kept in your ticketing or workflow system. Its production experience is deepest in insurance, a regulated financial sector, and it generates audit-ready evidence mapped to NYDFS.

Tradeoffs and practical next steps

Stronger verification adds friction and handling time. Apply it by risk: a read-only inquiry does not need the same checks as an MFA re-enrollment or a payment instruction change. Federal guidance on authentication points the same way, calling for periodic evaluation of authentication effectiveness and enhanced authentication for users who warrant it. Be cautious about calling any single method deepfake-proof. Callback and approval workflows reduce exposure, but your own testing and case reviews should show whether they hold up against a capable attacker.

A sensible sequence is to inventory the high-risk actions, close unilateral paths for the highest-risk ones, then update the risk assessment and training. Next, list every AI assistant or tool that touches these workflows and define which actions it may take alone, which need human approval and which are blocked. Finally, confirm that each of those decisions produces a record you can retrieve for an examiner. Frame the exercise as showing how existing Part 500 controls address AI-enabled social engineering, since that is how DFS positions the letter.