RDX Perspective
Most security tooling is built to find what stays. It looks for the thing that installed itself, the process that keeps running, the beacon that calls home on a schedule. The fastest growing class of attack aimed at executives does none of that. It arrives inside a normal business conversation, takes what it came for, and leaves. When nothing stays behind, detection is not the control that saves you.
What endpoint security assumes
Every mature endpoint product rests on one idea. An intrusion leaves a footprint that lasts long enough to be found. That is why we talk about dwell time, and it is why threat hunting is a discipline you can staff. Both only make sense if the intruder dwells.
That assumption has held up well. It fits ransomware crews, espionage operations, and anyone who needs to stay inside a network long enough to move around in it. It has shaped how we buy, how we staff, and what we report. Ask most security leaders how the program is doing and some version of mean time to detect comes up inside two minutes.
I wrote in July about an interview that turned out to be an attack. I am not going to retell that story here. What I want to talk about is the thing it exposed, which is a good deal bigger than one bad afternoon.
The attack that does not dwell
The pattern is simple enough to explain in a sentence. Somebody who has a plausible reason to be talking to you asks you to run something. You run it. It collects browser cookies and session tokens, saved passwords, the keychain if you typed your password anywhere in the process, and whatever secrets happen to be sitting in plain text on the disk. It packages that up, sends it out, and deletes the package.
Total elapsed time is minutes. There is no second stage waiting around for instructions. No scheduled task, no login item, no service, no implant. The theft is finished before you are done wondering why the screen froze.
In the case I looked at, no persistence was identified in the available evidence. I am phrasing that carefully on purpose, and I will come back to why near the end.
Three ways this breaks the model
Nothing remains to be found. Post incident hunting is largely the work of looking for what got left behind. When the honest answer is nothing, a clean scan is not reassurance. It is the expected result, and treating it as an all clear is how people talk themselves out of rotating credentials.
The follow on access is not an intrusion. This is the part I think is most underappreciated. Stolen session cookies do not require the attacker to log in at all. The session is already authenticated. Multi factor was satisfied when you satisfied it, and the token carries that fact with it. So the next access does not look like an attack. It looks like you, in a browser, holding a session that the system considers perfectly valid. Changing the password does not end it either, not unless you also revoke the active sessions.
It happens where no control lives. The interview, the vendor demo, the partner call, the diligence request. These run on whatever laptop the executive actually uses, over whatever meeting link the other side sent, with a person the organization has no relationship with yet. There is no agent policy governing that conversation, because the conversation is not a corporate system. It is a workflow. Until recently nobody owned it.
The question nobody owned
Endpoint tools answer a good question. Is something malicious running on this machine. That question has an owner, a budget, a dashboard, and a renewal date.
Here are three questions that had no owner at all.
Is this executive being manipulated right now, inside a workflow that sits outside every control we run.
What sensitive assets were actually reachable at the moment that command ran.
Do we have enough evidence to decide what to do, and could somebody else verify that decision later.
None of those are endpoint questions. They are governance questions about a human workflow. The fact that they had no home is a category gap rather than a product defect. The endpoint vendors are not failing at their job. They are doing their job, and the scope of that job was settled before this was the problem.
Executive Workflow Detection and Response
We started calling this EWDR internally, for Executive Workflow Detection and Response. It is deliberately not EDR, XDR, or MDR, and that distinction is not a naming exercise. Those products organize around signatures, behaviors, and telemetry coming off machines. This organizes around workflows, approvals, evidence, and decisions.
In practice it comes down to a few things.
The high trust workflows get treated as workflows. A recruiter interaction, an identity verification request, an unexpected vendor meeting, an executive appearance. Each becomes something with a state and a record, not just an entry on a calendar.
Exposure is known ahead of time rather than reconstructed afterward. You should be able to say what sensitive material is reachable from an executive machine today, before anybody has to ask under pressure.
Findings carry evidence that someone else can check, and the decisions made in response are recorded along with who made them and what they knew at the time.
Where an AI agent takes part in any of this, its reasoning and its actions get logged the same way a person's would. Secure the human, govern the AI, protect the enterprise. Those are three parts of one problem, not three separate products.
Blast radius is an inventory problem
Here is the most useful thing I took out of all of this, and it has almost nothing to do with malware.
The damage was not decided by how sophisticated the code was. It was decided by how much was sitting in plain text on the disk at the moment it ran. API tokens in environment files, a cloud credential in a working directory, SSH keys, tokens cached by developer tooling. Ordinary residue from getting work done.
That is a knowable number and hardly anyone knows it. Most organizations cannot tell you what secrets are on an executive or engineer laptop right now. If you know it before an incident, your response is a worklist that you run in priority order. If you learn it during an incident, your response is a scramble, at the worst possible moment, with no clear boundary on what needs rotating and no way to tell when you are done.
You do not need to buy anything to start on this. You need an inventory, sorted by what an attacker could actually do with each item, and the habit of making that list shorter.
Write conclusions somebody else can check
Earlier I said that no persistence was identified in the available evidence, rather than saying there was no persistence. That difference matters more than it sounds.
The first statement is one I can support. It describes what was examined and what was found, and it holds its shape under questioning. The second is a claim about the entire machine and everything on it, and I cannot prove that. If something had been present in a way the review did not cover, the second version quietly turns into a false assurance that other people made decisions on.
This is a small discipline that changes what the whole exercise is worth. Incident conclusions get read later by an insurer, an auditor, a contracting officer, or a board, and they get read at a moment when something is already going wrong. A conclusion that states its own basis survives that reading. A confident sentence with nothing underneath it does not.
It is the same principle we apply to autonomous systems. An action that cannot be traced back to an authority and an evidence trail is a finding, no matter how good the outcome looked at the time.
A clean scan is not the same as a safe conclusion.
What this means for you
If you are an executive, the uncomfortable part is that your own workflow is now in scope. The interview, the recruiter, the diligence call. Those are business processes, and they have earned the same skepticism you would apply to an unexpected wire transfer request.
If you sit on a board, the question worth asking is not whether the endpoint tooling is current. It is whether anybody can tell you what was reachable from a compromised executive laptop, and how fast the organization could revoke all of it. That is a capability question, and the answer tends to be vaguer than people expect.
If you run a federal program, the bar is higher. Valid session tokens carrying authenticated access into a bounded environment is a serious condition, and trying to reconstruct what happened after the fact, using tooling that was never watching the workflow in the first place, is not a position you want to defend.
And if you are reading this thinking it could not happen to you, I would point out as gently as I can that I do this for a living and it very nearly worked on me. That is the entire reason I keep writing about it.
Where this goes
The last decade of security was about getting visibility onto machines. The next stretch is about getting governance around workflows, including the ones where a human being is talked into something, and increasingly the ones where an AI agent is acting on our behalf.
Endpoint detection is not going anywhere and it should not. It is necessary. It is simply not sufficient against an adversary who never intended to stay.
Human led. Agent assisted. Evidence proven. Control the action. Prove the outcome.
William Farrell
Founder and CEO, RDX Enterprise, LLC
Secure. Automate. Optimize.
If you cannot currently answer what is reachable from your executives' machines, that is a good place to start and it costs nothing to find out. RDX Enterprise builds governed security operations, with a human in the loop and evidence behind every decision.