Practitioners First,
Vendors Second
We run deepfake simulations against real enterprises and research how AI-enabled threats behave in the field. What we find there decides what we build, and what we tell you.
Meet Our Team
Operators and engineers who spend their week in live engagements
Jason Thatcher
Cybersecurity veteran with 15+ years of experience, having led critical operations at GuidePoint Security, ZeroFox, and Deepwatch.
Adam D'Abbracci
Full-stack engineer with 15+ years building and breaking complex systems. Former Tech Lead at The New York Times and IAM at Disney.
Emma Francey
Crafts marketing strategies that cut through the noise, helping businesses understand and defend against AI-driven cybersecurity threats.
Clinton May
Leads development of our simulation capabilities and the research behind how AI-enabled threats behave in the field.
Jonas Kratzenberg
Builds the technical infrastructure powering Breacher.ai's simulation platform.
Geraldine Yap
Validates every release of the simulation platform so an engagement behaves in the field exactly as it did in testing.
Built From What We Find in the Field
We were among the first to run deepfake simulations against real enterprises. We still run them every week.
Breacher.ai was built by security practitioners, not marketers. We ran security operations, incident response, and offensive engagements before we built anything, and we still spend our week inside live engagements rather than writing about them.
When cybersecurity veteran Jason Thatcher first experimented with synthetic media in a home lab, the finding was not that the technology looked convincing. It was that convincing was never the hard part. The hard part was that the organizations on the other end had no procedure for what to do when the voice on the phone sounded exactly like the CFO.
We were among the first to run deepfake social engineering simulations against real enterprises, and we have been researching how AI-enabled threats actually behave ever since. Every finding from the field goes back into the platform and into what we tell customers, including the findings that are inconvenient for us.
Process Under Pressure
We test what happens after someone believes the call. The approval step, the verification step, the payment step, the access grant.
The Red Flags That Transfer
Urgency, secrecy, borrowed authority, and any request to step outside normal process. The pressure tactics behind a synthetic voice are the same ones behind a text message, and they are learnable in a way that pixel artifacts are not.
Escalation That Gets Used
A reporting path only counts if people trust it enough to use it mid-call. We measure whether it gets used, how fast, and what the security team does next.
Detection Is Not a Security Control
Teaching people to spot deepfakes is a losing bet, and it gets worse every quarter.
Most deepfake training rests on one assumption: show people enough examples and they will learn to tell real from synthetic. That assumption expired. Generation quality improves every month. Human perception does not.
In our simulations, the majority of people cannot reliably separate synthetic media from the real thing. The few who can are not the point. A control that requires every employee to be right every time, under pressure, on a call they were not expecting, from a face they recognize, is not a control. It is a hope.
Detection also fails quietly. Nobody reports the call they believed. By the time the failure is visible, the wire has cleared or the credential is in use.
Detection-first training
Procedure-first assurance
What the Data Says About Detection
Drawn from our own simulation benchmark and from public breach research.
Our figures come from a sample of enterprise simulations, not from every engagement we run. Aggregate numbers are context, not a benchmark. The number that matters to you is how your organization scores against your own peer vertical.
People, Process, and Technology. Tested Together.
Security is not one size fits all. Your testing and training should not be either.
Did they act, push back, or report?
Depending on the path, a person is the first line of defense, the last, or the only one. We measure what they did with the request, not whether they could spot a rendering artifact.
Did the procedure hold when someone senior applied pressure?
Did the wire, the credential reset, or the access grant require a second channel? Was the escalation path reachable in the moment? This is where consequential failures actually happen, and it is unique to every organization.
Did the tooling see any of it?
These campaigns land inside trusted communication platforms and travel through the seams between security tools. Every tool works as designed and nobody owns the gap. We test the gap.
Our OSES™ methodology, Orchestrated Social Engineering Simulations, builds the scenario around your approval chains, your executives, your platforms, and your escalation path. The simulation exposes where the procedure breaks. The training that follows reinforces that specific procedure, not a generic module about looking for blurry edges.
Practice announced. Assess unannounced. Measure the organization, not the individual.
Results That Matter
Find Out Where Your Process Breaks
See how your organization responds when the request comes from a face and a voice your team already trusts.
support@breacher.ai
