Process Invocation vs. Detection | Breacher.ai
Process Invocation vs. Detection
Users defeat our simulations in two ways. They become suspicious, or they invoke process. Only one of those is a control you can build a program on, and it is the one that does not require the user to be right.
We run orchestrated social engineering simulations against enterprise organizations as a paid engagement. Over two years of that work, across voice, video, and messaging, every sequence that a target stopped short of a consequential action was stopped in one of two ways.
The first is that the target became suspicious. The user sensed something was off, the target formed a judgment, and the sequence ended there.
The second is that the target invoked process. They did not conclude anything about the caller. They executed a verification step because the request belonged to a class of request that requires one, and the conversation moved to a channel our operator could not follow.
Those two outcomes look identical in a report and they are not remotely the same control. One of them is a property of the person and the generator. The other is a property of the organization.
Two Ways Users Defeat a Simulation
The target becomes suspicious
This depends on perception. It works when the synthetic artifact is imperfect enough for a human to catch, which means its reliability is set by the quality of the generator rather than by anything the organization did.
You cannot budget for it, you cannot audit it, and it gets worse every quarter without anyone touching your program.
The target invokes process
This depends on the request, not the artifact. The person does not have to be right about the caller. They only have to recognize that a credential reset was requested and that credential resets get verified out of band.
It is written down, it is testable, it produces a record, and it returns the same result against a crude fake and against a perfect one.
Why the Gap Widens in One Direction Only
Perception is fixed. Generator quality is not. That asymmetry is the whole argument, and our own numbers show it moving.
The live agentic figure was in the low single digits of targeted users when we started measuring it. It is now around one in ten. We did not get better at this. The models did, and we held our methodology constant while that happened.
Run that forward. There is no release schedule on which human discrimination improves, and there is a release schedule on which synthetic fidelity improves. A control whose effectiveness is an inverse function of the adversary's tooling is a control with a depreciation curve attached, and the adversary sets the rate.
The Rule: Is the Tell an Artifact or a Perception?
This is where the argument gets useful rather than merely correct, because it is not an argument against detection training. It is an argument about where detection training belongs.
A phishing domain leaves inspectable evidence. A wrong sender address, a mismatched URL, a freshly registered certificate. That evidence holds still under scrutiny, it can be re-examined deliberately, and it does not improve as attacker tooling improves. Detection training against an artifact is a durable skill.
Synthetic voice leaves nothing to inspect. The only instrument is the listener's ear, the signal is transient, and it degrades with every model release. There is no artifact to hover over and no header to expand.
| Signal | What the tell is | Train detection? |
|---|---|---|
| Sender address and headers | Artifact. Persists, can be expanded and read | Yes |
| Domain and URL path | Artifact. Can be hovered before clicking | Yes |
| Certificate age and issuer | Artifact. Checkable, and does not improve with tooling | Yes |
| Synthetic voice on a call | Perception. Transient, no evidence to inspect | No |
| Synthetic face in a meeting | Perception. Same instrument, same decay | No |
| An ordinary request from a known colleague | No tell at all. Nothing is wrong with it | No |
The last row is the one most programs have no answer for. A request can be entirely legitimate in appearance and still be the attack, because the pretext is an expected workflow rather than an alarming one.
Where This Argument Stops
Two bounds, stated up front, because the compressed version of this position gets flattened into something we do not believe.
This is not a case against detection technology. It is a case against locating detection in human perception. Machine identity verification is a real control and we are firmly in favor of it, particularly in the hiring path: document verification, liveness checks, validation against authoritative sources, and synthetic media detection on the interview channel, enforced as a hard gate before any access is provisioned. Our role there is to test whether those controls hold, not to argue them away.
Procedural invariance is not total, either. Better synthetic media does not defeat a verification step directly. It raises the pressure applied against it, because a more convincing executive makes granting the exception feel more reasonable. What degrades with generation quality is not the control, it is the exception rate. That is measurable, and measuring it is more defensible than claiming a control that never fails.
Bind Verification to the Request Class
The practical implication is a single design decision. Bind the verification requirement to the class of request, not to the user's suspicion.
Four classes carry most of the consequential exposure. Each one gets out-of-band verification every time, from anyone, whether or not anything felt wrong.
Funds movement
Outbound payments, and vendor banking detail changes in particular. The banking detail change is the one most often missing a written step, because it arrives as an administrative update rather than as a payment.
Credential resets
The class our voice simulations request most often, because it is routine, it is delegated to a service desk, and the requester is frequently someone the recipient has never met.
Multi-factor enrollment, reset, or bypass
Enrolling a new device is the quiet version of this and it is functionally a credential handover. A verification step here is worth more than most of the tooling sitting in front of it.
Privileged data extracts
Payroll files, customer records, employee rosters. These rarely trigger anything because no money moves and no account changes, which is exactly why they are requested.
The test for adding a fifth is narrow: one human action, and an outcome that cannot be reversed on Monday. The failure mode is scope rather than strictness. Four to six classes is a program. Fifteen is theater with an audit trail, because people route around all of it including the classes that needed it.
And the rule has to be unconditional. If the person has to decide whether this particular request qualifies, you have rebuilt detection training and given it a procedural name.
What the Callback Actually Does
Callback verification works for a more specific reason than most people state, and the reason is worth naming precisely because it is what makes the control invariant.
It converts a perceptual problem into an artifact problem.
The question stops being whether the voice sounds real, which is unanswerable and getting more so. It becomes whether the number you dialed came from the directory or from the request. That second question has an artifact attached. There is a record, it can be checked, it can be audited afterwards, and the answer does not change no matter how good the voice was.
Which means the channel is the entire control. A callback to the number in the email signature is a procedure that ran and failed, and so is a confirmation sent as a reply on the same thread the request arrived in. If the requester supplied the channel, the check confirms nothing except that the caller answered their own phone.
What It Looks Like When It Holds
We saw this in a recent voice-led simulation using an IT support pretext, run against a shortlisted population of 37 targets.
Some of those targets ended the sequence by invoking a verification step. They did not identify the caller as synthetic and, on the audio quality in play, most of them would not have been able to. They recognized the request class and moved the decision to a channel our operator could not reach.
The same population also produced consequential actions, and that is the part worth sitting with. The difference between the targets who stopped it and the targets who did not was not perceptual skill. Nobody in either group could reliably tell the voice was generated. The difference was whether a verification step existed for the request they received and whether they ran it.
That is a coverage finding, not a training finding, and it is the finding most engagements actually produce. We take the measurement apart in the field findings from our callback log, and the upstream argument for why detection decays in the first place is in Deepfake Detection Training Is a Decaying Control.
What to Measure
The last question is the coverage rate, and it is the number most organizations have never calculated. It is also structural, which means it can be assessed without running a simulation at all.
What We Would Do First
None of this requires a purchase, and all of it is executable this week.
- List your consequential request classes. Four to six lines. One human action, irreversible outcome.
- Check which ones have a written verification step. The gaps are usually credential resets, multi-factor enrollment, and data extracts, because the wire transfer got a process years ago and the others never did.
- Rewrite every step so it names the channel. Verify the request is not a procedure. Call the number held in the directory is.
- Make the trigger the request class. Strip out every conditional clause that begins with if it seems suspicious.
- Confirm the step leaves a record, then test one class adversarially and report which of the four outcomes you got.
Detection cannot be the control. Process carries every high-consequence request class, and detection is the backstop for the long tail you failed to enumerate.
Frequently Asked Questions
Should we train employees to detect deepfakes?
Not as a control you intend to rely on. Detection training earns its place where the tell is an inspectable artifact that holds still under scrutiny, such as a sender header, a mismatched domain, or a freshly registered certificate. Synthetic voice and synthetic video leave no artifact the listener can inspect. The only instrument is the ear or the eye, the signal is transient, and it degrades with every model release. Train detection where the tell is an artifact. Use a verification procedure where the tell is a perception.
What is the difference between an artifact tell and a perceptual tell?
An artifact tell is evidence that persists and can be checked deliberately. A URL can be hovered, a header can be expanded, a certificate date can be read, and none of that evidence improves as adversary tooling improves. A perceptual tell exists only in the moment of hearing or watching, cannot be re-examined, and gets harder to catch every time a generation model ships. That is why detection training against phishing artifacts is a durable skill and detection training against synthetic media is a depreciating one.
Which requests should always require verification?
Four classes cover most of the consequential exposure: funds movement, including vendor banking detail changes; credential resets; multi-factor authentication enrollment, reset, or bypass; and privileged data extracts. Each of these gets out-of-band verification every time, regardless of who is asking and regardless of whether anything felt wrong. The trigger is the class of request, not the state of the recipient. If the person has to judge whether this particular request qualifies, the control has been handed back to perception.
Does binding verification to the request class slow the business down?
Less than an unscoped policy does, because the list is short and the rule is unconditional. The cost comes from scope, not from strictness. Put a verification requirement on everything and people route around all of it, including the requests that needed it. Four to six classes is a program people can hold in their heads and run at four in the afternoon. The test for inclusion is narrow: one human action, and an outcome that cannot be reversed on Monday.
How do you test whether a verification procedure actually holds?
Make the request the procedure is supposed to govern, through a channel the procedure is supposed to distrust, and record four separate outcomes rather than one. The step ran and the requester was refused. The step ran and the requester satisfied it anyway. The step was skipped. The step was never written. Those are four different failures with four different owners, and a click rate collapses all of them into a single number that names none of them.
See Which Request Classes Have No Verification At All
We make the request your written step is supposed to govern, then report whether the step was invoked, skipped, satisfied by the caller, or never written in the first place.
Book Your DemoLatest Posts
Table Of Contents
About the Author: Jason Thatcher
support@breacher.ai
