Shift 8 numbers: 25 alerts, 15 escalations, 14 at immediate urgency. Confirmed Cobalt Strike on a production Active Directory server. Lateral movement to three domain controllers. A krbtgt rotation requirement. Twelve hosts flagged for isolation. Credential exposure across nine named accounts plus two identities treated as attacker-controlled. By operational severity, this is the most significant shift EOTG has run right. Right at the midpoint of Phase 1.
That’s not what I want to write about.
TL;DR: The agents performed correctly. TORA escalated on the right signals. VERA found pre-existing compromise behind twelve phishing alerts and named lateral movement to domain controllers. The verdicts are accurate and the audit trail is clean. What neither agent produced (because no process required it) was an answer to the question that matters most when you find a host that was already compromised before the alert fired: how long, and how did it get there. That’s not an agent capability problem. It’s a process debt problem. Agentic AI doesn’t fix process debt any more than prior automation waves did. It amplifies what’s already there.
What the agents found
TORA triaged 25 alerts across five days: phishing delivery, credential harvest, DNS tunneling, fast flux, and standard malicious lookups. Every forced escalation rule fired correctly. The O365 gateway delivered confirmed-malicious emails to recipient inboxes on seven separate occasions. TORA named the pattern on the first case on May 11 and tracked it through May 15. That’s shift memory doing what it’s designed to do.
VERA investigated 15 cases. In 12 of 14 resolved cases, VERA refined TORA’s hypothesis, not because TORA reasoned incorrectly, but because endpoint telemetry revealed something TORA couldn’t see from the alert surface: the host was already compromised before the alert fired. CASE-20260512-0008 is the clearest example. TORA escalated a phishing delivery alert for j.kim on ws-mktg-042.corp.local. VERA found a LOLBin execution chain under a different user account, alee, with an active C2 beacon running at 82-second intervals, and the process start time was eight minutes before the phishing email arrived. Two related alerts on the same host, an SMB lateral movement attempt and a process injection detection, had both been closed independently earlier in the shift. TORA’s phishing case was the third alert on a host that was already confirmed-compromised by the time TORA saw it.
That refinement from phishing entry point to pre-existing intrusion is exactly what T2 investigation is supposed to produce. VERA did the work. The verdicts are accurate.
The question nobody asked
srv-jump-01.corp.local was the most significant asset in the shift. Two confirmed credential submissions from executive users, confirmed C2 beaconing, lateral movement to a critical database host and two development servers, attacker tooling under a third identity (ctaylor) that has no business being on a jump server at all. VERA’s finding on VERA-20260511-0003 is unambiguous: a fully staged malware implant was already running on srv-jump-01 when c.wardlaw clicked the phishing link. The credential submission was not the intrusion. It was an event on a host that was already gone.
Neither agent asked when.
Not because they can’t reason about time. VERA reconstructed pre-delivery process start times across four separate cases. The capability is there. But nobody defined a process that says: when you find pre-existing compromise behind a triage event, your first task is to establish origin and dwell time before you move to containment. How long the host was compromised, and what the actual entry vector was, is the difference between an isolation action and an incident investigation. ARIA received an isolation list and credential resets. The forensic timeline that would tell you whether srv-jump-01 was compromised three days ago or three months ago, and by what means, went unasked.
That question doesn’t get answered by a smarter agent. It gets answered by a process that requires it.
The process debt problem
There’s a pattern in security tooling that recurs every time a new automation capability gets introduced. A team adopts the technology because the problem is real:
- alert volume is too high,
- analysts are overwhelmed,
- response time is too slow.
The technology works. Tickets close faster. Metrics improve. And at some point someone notices that the security posture hasn’t actually improved, because the automation was running on top of processes that were never right to begin with. The tool amplified what was already there, which is exactly the problem.
Agentic AI is different from prior automation in one important way: the agents can reason, not just execute. VERA didn’t just close a ticket on CASE-20260512-0008. The investigation contradicted the original alert framing and named an entirely different threat actor account as the execution identity. That’s not execution speed. That’s judgment. But judgment still operates inside a process frame. The judgment VERA applied was to the question in scope. The question in scope was: what happened on this host in the window around this alert? That’s a good question. It’s not the complete question.
A mature SOC process for an intrusion of this type would define a minimum set of required questions at T2: not just what is active, but when did it start, what was the likely entry vector, and does the blast radius extend further than the telemetry I have now? Those questions don’t emerge from better prompting. They come from playbooks: documented decisions about what investigation completeness means for a given alert type and escalation path. The playbook is what tells VERA that a phishing case with pre-existing compromise is not a phishing case anymore. It’s a breach investigation with a phishing trigger, and the scope and the evidence requirements are different.
Without that process foundation, the agents produce accurate outputs on the questions they’re asked and leave the most consequential questions unscoped. The alert queue clears. The verdicts are defensible. And the dwell time on srv-jump-01 remains unknown.
What this means for Phase 2
NOVA’s job is to close the feedback loop, to surface patterns across shifts that neither TORA nor VERA can see within a single investigation. The IDS/netflow DNS discrepancy that VERA flagged on VERA-20260515-0020, the recurring prior-alert closure pattern across four cases this shift, the telemetry-cloud-api.com domain appearing in five cases without ever entering a TORA indicator set: these are exactly the inputs NOVA needs to generate detection engineering feedback. That structural capability matters.
But what NOVA surfaces only has operational value if there’s a process to receive it. A pattern finding about prior alert closures preceding confirmed compromise is useful if there’s a decision framework for updating alert handling procedures. A recurring domain that bypassed TORA’s indicator sets is useful if there’s a defined path from NOVA’s observation to a detection engineering action. The feedback loop NOVA closes is a technical one. The loop that turns a finding into a changed process is a human one, and it has to be built first.
The agents are infrastructure. I’ve written that before. What Shift 8 is teaching me is what that means at the process layer: infrastructure executes what the process requires. If the process requires the right questions, the agents will answer them. If it doesn’t, the agents will answer something adjacent, accurately, thoroughly, and with full audit trail, and the question that mattered will go unasked.
That work isn’t a future phase item. It’s the precondition for everything else.
— Jeny Teheran
Eyes on the Glass, May 16, 2026