Helpfulness is the attack surface
Every quality you train into a chat agent — responsiveness, empathy, a bias toward solving the problem rather than citing policy — is a quality an attacker can use. Social engineering against support does not look like hacking. It looks like a stressed customer who cannot get into their account, who is about to miss a deadline, and who just needs you to update the email address on file. The agent who helps is doing precisely what you asked them to do. That is why this is a training problem, not a character problem.
The patterns worth recognising
Most attempts combine urgency with a small, reasonable-sounding request. A deadline that makes verification feel obstructive. Authority, real or implied — a claim to be an executive, an administrator, or an IT contractor. Salami tactics, where several short chats each extract one harmless fragment, and the fragments assemble into an account takeover. And the classic pivot: an inability to pass verification reframed as your failure, in the hope that an agent will waive the check to end the discomfort. None of these look like attacks in the moment. They look like a bad day.
Give agents permission to be slow
The single most effective control is cultural: an agent must know, with total certainty, that they will never be criticised for verifying. If your dashboards reward speed and your reviews punish slow handling, you have quietly instructed agents to skip checks under pressure — and attackers apply pressure deliberately. Say it explicitly, and mean it: no one is ever in trouble for taking the extra minute. An agent who has been told this once, in writing, is far harder to rush.
Escalation is a shield, not an admission
Agents need a no-fault exit. Handing a suspicious conversation to a senior colleague should carry no implication that the agent could not cope; it should be the expected, praised response to a specific pattern. In practice, that means naming the trigger conditions in advance — requests to change a recovery email or phone number, requests to bypass verification, anything invoking urgency plus authority — so escalation is a rule the agent follows rather than a judgment call they might get wrong. Rules protect people. Judgment calls under time pressure do not.
Review the misses without blame
When an attempt succeeds, or nearly does, the transcript is the most valuable training material you will ever have. Read it as a team and ask what made the request feel reasonable, because it did feel reasonable. Teams that treat these as blameless learning cases surface the near-misses; teams that hunt for someone to blame simply stop hearing about them, which does not make the attempts stop.
How MyLiveChat fits
MyLiveChat keeps a full transcript of every conversation, so a suspected attempt can be read back word for word and turned into training rather than reconstructed from memory. Departments and routing let you send account-sensitive conversations to the smaller group trained to handle them, and canned responses give agents ready-made, non-confrontational wording for asking a verification question — which is when improvising is hardest and matters most.
A script for the three most common asks
Agents fold under social pressure because they have nothing prepared to say. Giving them one rehearsed sentence per situation converts an uncomfortable judgement call into a routine.
- “I have lost access to my email, can you change it?” → “I can start that, and for account changes it has to go through the recovery process rather than chat — here is the link, and I will stay with you while you do it.”
- “I am calling about my colleague's account, they are on leave.” → “I can only discuss an account with the person on it or a named contact. If you tell me the company I can check who is listed.”
- “This is urgent, your manager said you would sort it.” → “Happy to help — let me confirm that internally and come straight back.” Urgency plus borrowed authority is the classic pairing, and the answer to both is a pause.
Notice that none of these refuse. They redirect to a channel that can verify, which keeps the interaction helpful for the ninety-nine percent of askers who are exactly who they say they are.
Build a pretext file
Attempts against your team will rhyme with each other, because whoever is trying knows what works on companies like yours. Writing them down turns individual experience into team knowledge.
Keep a short shared note. Each entry needs four things: what was asked for, the story used to justify it, what tipped the agent off, and what the agent said. No blame, no names. Read it out when someone joins, and add to it whenever anything feels off — including the times nobody was sure. The near-misses are the most useful entries, because they describe the pressure that almost worked.
Review it every few months against your actual policies. A recurring pretext often points at a genuine gap: if people keep talking agents into email changes, the real problem may be that your legitimate recovery flow is painful enough that customers look for a human shortcut. Fixing the flow removes the pressure at source, which is a better outcome than training agents to withstand it forever.
What to measure
This is one of the few areas where the useful signals are qualitative. Count logged attempts per quarter, and read a rise as better reporting rather than a worsening threat — the number you should worry about is zero, which almost always means people are not writing them down. Track how often an agent used the escalation path, because an escalation route nobody uses is not a control. And check the time to escalate: the goal is that a suspicious request goes to a second person in minutes rather than after the agent has spent twenty minutes being talked round.
Once a year, run the pretext file as a five-minute drill. Read out three of the stories and ask the team what they would say. It surfaces the ones where everybody would have quietly complied, which is exactly the training you need and cannot get from a policy document.
Scripted abuse is a different problem from the human kind, and it can be stopped earlier. The filter that rejects spam before it becomes a chat covers refusing a submission outright, and why it is built to fail open.