A senior engineer is in their last week. They have admin rights on their laptop and access to several privileged cloud profiles. Sitting at their own console, they open a terminal and start an AI coding agent with its permission prompts turned off. Over the next 64 minutes, that agent launches more than a hundred processes. It searches a credentials handoff file and the shell history for cloud keys, source control tokens, chat tokens and private keys. It finds compensation documents and deletes them. It removes a scheduled job from a service account's crontab. It terminates two cloud instances, 56 seconds apart, using two different administrative profiles. Then it runs a log cleanup script with elevated privileges and deletes the script.
The endpoint detection tool raised an alert 40 seconds after the last command finished.
This happened in a customer environment. Command Zero investigated it on its own from start to finish, and the customer confirmed the result. I've removed anything that identifies the customer, but I want to explain what the investigation found and how it found it. I think it's an early example of a kind of incident most SOCs aren't set up to handle. The full file is in the Casebook: the five-phase timeline, the decision path and the evidence behind each answer. Read the investigation.
Three Medium alerts and nothing that looked urgent
The final hour was only the last part. The activity started three days earlier, and the EDR alerted all three times. Each alert was Medium severity.
On the first day, the user sent a base64-encoded Python payload over a cloud session manager to a container running an internal CRM application. The payload pulled open sales opportunities and calculated weighted pipeline revenue. On the second day, the user ran more payloads against two other containers on the same host. Those payloads read the full HR employee export, built the management hierarchy from supervisor IDs, followed QA and test engineering reporting chains up to eight levels, and searched for specific people by name. They also opened the admin and auth databases read-only and listed every table, with row counts and columns.
The first two alerts were closed as resolved. When you look at them one at a time, that decision makes sense. A senior technical person running Python through session manager against company infrastructure is normal in plenty of organizations. The third alert was still open when the investigation began.
I ran tier-3 queues for a long time, and this is the pattern I worry about most. Analysts are trained and measured on single alerts. Was this one event malicious? Usually it wasn't. Insider activity hides well under that model because every step is something the person has permission to do. The intent shows up only when you line the steps up in order, and a queue built for throughput doesn't do that.
Why an agent makes this harder
Insider threat programs depend on time, even if they don't say so. A departing employee who wants to take credentials and cover their tracks has to do it by hand: find the files, write the greps, remember which cloud profile can reach which instance, write a cleanup script that doesn't fail. That takes hours or days and tends to leave mistakes behind. Detection, HR review and offboarding all have room to catch it.
An agent compresses that. The person states what they want and the agent produces the regexes, figures out the profiles, writes the cleanup script in its scratch directory, copies it out, runs it with privileges and deletes it. Credential collection, destruction and anti-forensics all finished before the alert fired. The EDR saw it happen, but nothing blocked any of it.
The real issue is access. Anyone with admin rights and a coding agent can now run a fairly disciplined exit campaign quickly. Defenders who need a full day to piece together three days of activity are behind before they start.
What the investigation did
The investigation started from the open alert and pivoted by itself from there. It anchored on the account's SID and the device's machine ID and then pulled what it needed: logon events across the window, process creation trees, device properties and group memberships, and the other two alerts on the same account. It decoded the base64 payloads from the session manager command lines. That's how the CRM query, the HR graph traversal and the database enumeration showed up as readable code.
It produced a five-phase timeline over three days, from CRM reconnaissance to cleanup. It identified the process lineage behind all of it: agent binary, then shell, then aws, grep, rm, crontab and osascript. That chain appears the same way in more than a hundred process events. It also recorded that the agent ran with its permission-bypass flag on every time.
It then went through a 13-question decision path to reach a verdict. Several of the questions are ones a careful tier-2 analyst would ask:
Can this be explained by legitimate operations or analyst notes? No. Does it fall within the user's role, done the way it was done? No. Did a security control block it? No. Did an authorized user with legitimate credentials do things they would reasonably know were malicious? Yes, and the platform marked that answer as having conflicting evidence instead of hiding the conflict. Is there evidence of intent, such as systematic collection, concealment or access outside the role? Yes.
The verdict was malicious insider activity. Confidence was High, and the investigation said explicitly why it was not Confirmed.
Why the confidence statement matters
For me this is the most important section of the report, and it's the reason I think AI investigation has to be glass box.
Since an agent ran the commands, there are two other explanations to deal with. One is prompt injection: the agent read something hostile and acted without the user knowing. The other is that the account was compromised and someone else was at the keyboard. A black-box verdict would rule both out without saying so, and you'd be asked to trust it.
This investigation addressed both directly. All 17 logons in the window were local console sessions, with no remote IP, no remote device and no remote session flag. The permission-bypass flag has to be turned on deliberately. The deleted compensation spreadsheet had the account holder's own name in the filename. The payloads used three privileged cloud profiles, which an outside attacker would have had to steal separately. The activity built up over three days in a way that looks like a person working through a plan.
It also stated what it could not rule out. There was no recorded session and no prompt the user typed. Attribution is based on strong indicators, not direct proof, so a sophisticated prompt injection is still possible, though unlikely. That uncertainty is exactly what an analyst, an HR partner or a lawyer needs to see before acting on a verdict about an employee. The analyst who reviewed it also adjusted the severity, and the report shows that edit. The human made the final call with full visibility into how the verdict was reached.
The leads it handed back
The investigation also returned ten leads for follow-up. Some stood out:
- A second macOS device had root-level grep activity and a browser-harvesting script running from a UUID-named temp directory. It may be related or may be a separate problem, but it needs a look.
- The service account whose crontab was changed is tied to a keychain-guard daemon and two credential migration scripts.
- Two more cleanup scripts with exit-day names were found in the home directory, and one was run as root minutes before the instance terminations.
- The agent's own artifacts: the scratch directory, shell snapshots and project transcripts. If a prompt injection did happen, the transcripts are the most likely place to show it, and the investigation said so.
- Files the user moved to a dated trash folder, including an audit log export, an AI code attribution report and an IOC list. People don't usually tidy those away by accident.
The report also included containment steps, credential rotation scoped to the specific files that were read, and coordination items for HR and legal. The customer worked through these and confirmed the finding.
What I'd take from this
Watch agent process trees. A coding agent that spawns a shell, which then runs cloud CLI destroy commands, greps shell history or edits another account's crontab, is about as clear a signal as you'll get, and it's easy to hunt for. The permission-bypass flag shows up on the command line. Look for it.
Stop treating one-off Medium alerts on privileged users as closed. The first two alerts here were correct and they were closed correctly as single events. The mistake was handling them separately from each other.
Remove plaintext credential handoff files. A file named for credential handoff on someone's desktop is what an exiting user will reach for first, whether or not an agent is involved.
Most of all, the investigation has to move as fast as the attack. What agents changed is speed. If reconstructing a three-day insider campaign still requires an analyst to switch between five consoles for a full shift, the gap will keep growing. In this case the platform finished its autonomous analysis in 7 minutes 39 seconds. It tied the alerts together, decoded the payloads, weighed the other explanations and laid out its reasoning, and the human review took the time a human review should take.
If you want to check the reasoning yourself, the full investigation shows every question the platform asked, the answers it got and where it marked evidence as conflicting.
