AI makes familiar attacks faster and more convincing. It does not change who has to make the call.
In AI Can Run the Playbook. It Can't Make the Call., I argued that AI belongs on the defender's side of the table doing preparation work, while people own the decisions. This piece covers the other side: what to do when the attacker is the one using AI.
My position is simple. You do not need to prove AI was involved before you respond. If there are signs of fraud, a compromised account, exposed data, or unauthorized activity, treat it as an incident and run your plan. Whether a human or a model wrote the phishing email does not change the next step.
What an AI enabled attack actually looks like
Mostly, it looks like the attacks you already know. Phishing, supplier fraud, account takeover, and executive impersonation, made more personalized and easier to scale.
That is why I tell clients to stop training people to spot "AI written" messages. Polished grammar is not a warning sign anymore. Train them to spot unusual requests:
- An urgent payment or a change to supplier bank details
- A request to reset credentials, share confidential information, or skip normal approval
- A voice or video message asking for something unusual that cannot be verified independently
- Unexpected sign-ins, unfamiliar devices, or repeated MFA prompts
- New mailbox forwarding rules, permission changes, or supplier account changes
- Unexplained file encryption, suspicious processes, or unusual outbound data transfers
- A sudden burst of similar messages hitting employees, customers, or suppliers
A familiar voice, a polished email, or a convincing video is not proof of identity. For high risk requests, verify through a separate channel you already trust: a known phone number or your existing approval process.
Here is how that fails in practice. A finance clerk gets an email from the CFO asking to update a supplier's bank details before Friday's payment run. The clerk does the right thing and calls to confirm, using the number in the email. A cloned voice answers and approves the change. The control did not fail because the voice was synthetic. It failed because the attacker supplied the verification channel.
I see most mid-market organizations acknowledging AI driven risk while rarely rehearsing a response to it. Awareness is not readiness. The gap closes in practice, not in a policy document.
Step 1: Activate the plan
Report the incident through your established process. Do not run a serious event through scattered texts and individual heroics.
Start an incident log immediately. Record when it was noticed, who reported it, how it was found, and what has already been done. List the accounts, devices, systems, suppliers, and business processes that may be involved.
Notify your incident lead and the security or IT team. Escalate early if payments, sensitive data, critical services, or customer operations are at risk. If email or collaboration tools may be compromised, move coordination to an approved out of band channel.
Step 2: Contain and preserve evidence
The goal is to stop further harm without destroying what responders need. Coordinate containment with the incident lead. Pulling a device off the network or disabling an account is often necessary. Done without coordination, it can disrupt operations, alter evidence, or interfere with the investigation.
Typical containment actions:
- Disable a confirmed compromised account or revoke its sessions
- Rotate exposed credentials, tokens, or API keys
- Block malicious messages, domains, or files through approved processes
- Freeze suspicious payments or supplier record changes
- Restrict access to affected data or services
- Preserve messages, email headers, logs, files, screenshots, and timestamps
If money already moved, speed decides whether you get it back. Call your bank immediately and request a wire recall. Then file a complaint with the FBI's Internet Crime Complaint Center at ic3.gov. Do not wait for the internal investigation to finish first.
For any suspected impersonation, stop using the contact details in the suspicious message. Verify through a known, independently sourced contact.
Step 3: Establish what happened
With containment underway, figure out how access was gained, which accounts and systems are involved, and whether activity is ongoing. Qualified security or IT responders lead this, with outside incident response support when needed.
Separate confirmed findings from assumptions. Write down what you do not know yet.
AI tools help here when your logging and integrations support them. They summarize alerts and assemble a first timeline quickly. Treat that output as a draft. Verify it against source logs, identity activity, and tickets before anyone makes a consequential decision on it.
Step 4: Decide with impact in mind
I covered the decision framework in AI Can Run the Playbook. The short version: weigh confidence, impact, urgency, and reversibility. Automate approved, low impact actions that are easy to undo, and only within the scope each action was authorized for. Reversible is not the same as authorized. Put a named, authorized person on anything that disrupts critical services, touches customers, carries legal consequences, or is hard to reverse. Escalate the ambiguous cases.
Step 5: Bring in the right people
A serious incident is rarely just an IT problem. Depending on what happened, pull in leadership, legal, privacy, finance, communications, business continuity, and key service providers.
Legal and privacy assess notification obligations based on the facts, the law, your contracts, and jurisdiction. Not every incident triggers the same notice or the same deadline. One incident lead keeps the decision record and the single source of updates. That limits rumors, conflicting instructions, and the spread of attacker controlled content.
Step 6: Communicate clearly
Tell employees what is affected, what not to do, where to report suspicious activity, and how to verify urgent requests.
If customers or suppliers may be affected, prepare messages with legal, privacy, and business leads. Share confirmed facts, tell people what to do, and update as you learn more. Do not speculate about AI involvement unless it is established and relevant.
Step 7: Remove the cause and restore safely
Close the access route or vulnerability before bringing systems back. Recovery can include removing unauthorized access, fixing configurations, rebuilding compromised devices, restoring tested backups, reviewing privileged access, and watching restored systems closely.
NIST's current incident response guidance, SP 800-61 Revision 3, treats incident response as part of overall cybersecurity risk management, from preparation through recovery and improvement. I agree with that framing. Response is not a separate event from how you run security every day.
Step 8: Review and get better
Run the review without hunting for someone to blame. Did staff know how to report? Was decision authority clear? Did escalation work? Did technical and business teams have what they needed?
Update playbooks, contact lists, approval workflows, supplier controls, and employee guidance where gaps showed up. Add AI scenarios to training, focused on verification and decisions, not on guessing whether a message was machine written.
Invest in logging. Without reliable logs you cannot tell how far an incident reached, and you will be guessing in front of your board, your customers, and possibly a regulator.
First hour checklist
Use this next to your incident response plan, not instead of it.
- Notify the incident response lead.
- Start an incident log with known facts, actions, and times.
- Preserve messages, logs, files, and screenshots.
- Identify potentially affected accounts, devices, services, and data.
- Coordinate containment with the response lead.
- Freeze suspicious payments or supplier changes. If money moved, call the bank now.
- Move coordination to a trusted channel if needed.
- Notify the security, IT, leadership, legal, privacy, and finance contacts that the incident's severity and impact call for.
- Assign the technical investigation and the business impact assessment.
- Record decisions, approvals, unknowns, and follow up actions.
Decide before the incident, not during it
Your plan should say what triggers escalation, who can approve disruptive actions, which actions can be automated, and where automation stops for human review. It should define how staff verify high risk requests, preserve evidence, communicate securely, and bring in outside help.
This is especially important for organizations with 50 to 500 employees. The CFO, the IT lead, and the person approving the wire are often a handful of people. One convincing call can reach all of them in an afternoon.
Rehearse it. Run tabletops on a supplier payment change, an executive impersonation, and suspicious activity in a critical system. Test the handoffs between security, finance, legal, and leadership, not just the technical response.
AI helps your team move through information faster. It cannot supply the business context, the authority, or the accountability a consequential decision requires. Let the tools prepare the picture. Make sure a person owns the call.
Active incident? Call the Antares incident response line at (312) 725-0296.
Planning ahead? Book a consult to review your incident response plan or run a tabletop on your decision points.
