At the Corner of Wit's End and Shady

Monday, April 20, 2026

The Honeymoon Rate: AI Echoing the Dot-Com Boom/Bust

TL;DR: AI is real. Current AI pricing is not. The technology is new. The business model dynamics are not. Adopt aggressively, commit cautiously, and build everything to survive a provider change, a price correction, or the startup you depend on disappearing.

We've seen this movie before

In my conversations with enterprise leaders over the past year, I keep seeing two failure modes. Smart people, under board pressure to show AI adoption, are making fast commitments on unstable ground. They sign contracts, build dependencies, and defer the hard questions about what happens when the pricing changes. The pressure to show progress is producing decisions optimized for the next board deck, not for the next five years.

Other organizations demand FedRAMP authorization from two-year-old startups, five-year support commitments from providers that won't be profitable for four, and compliance guarantees against regulations that haven't been written yet. By the time the requirements document is finished, the technology has moved on. These organizations aren't being prudent. They're applying procurement frameworks built for a stable market to a market that is anything but.

Both groups are making the same error from opposite directions: treating a volatile, immature market as though it were stable.

This is genuine technology following a well-documented market cycle. The technology is new. The money isn't. VC-funded market capture, subsidized pricing, dependency building, and eventual correction: we've run this playbook with cloud computing, with ride-sharing, with the original dot-com platforms.

You're not paying the real price for tokens

Nobody has had to charge the real price of a token yet. OpenAI won't be profitable until at least 2030. The investor documents are public and they all say the same thing: the leading AI providers are selling below cost to capture the market. This isn't controversial. It's the stated strategy.

Every cost-benefit analysis I've reviewed uses today's token pricing as the baseline. Today's pricing is a promotional rate. That's not a reason to avoid AI. It is a reason to be skeptical of any business case that treats current pricing as permanent.

Uber didn't disrupt taxis: it subsidized them until the real price came back

Uber entered markets by sidestepping taxi regulations and using venture capital to subsidize rides. In Madrid in 2014, Uber's hourly subsidy to drivers was nearly twice the fare it charged riders. Internal presentations described this as "buying revenue."

Then Uber went public. Prices climbed roughly 18% per year. Drivers took home 12% less per trip. Nobody at Uber decided to make the service worse. Going public means the investors who funded the subsidy expect their return. The squeeze is structural.

OpenAI and Anthropic are both expected to IPO this year. When they do, the same structural pressure arrives. The investors who funded $207 billion in compute aren't philanthropists. That return comes from somewhere.

Automating a bad process just makes it fail faster

Rory Sutherland called it the Doorman Fallacy in Alchemy (2019). A hotel replaces its doorman with an automatic door. Two years later the hotel's reputation has tanked, because the doorman wasn't just opening the door. He was greeting regulars, providing security, hailing taxis, and signaling that the hotel valued its guests enough to put a human at the entrance. The consultant defined the role by its most visible task and destroyed everything else.

This shows up in AI-driven "efficiency" initiatives. A company replaces its sales intake team with a chatbot that collects the same information. But the sales team wasn't just collecting information. They were reading the customer, qualifying fit, and building the relationship that carries the account through the first product hiccup. The chatbot does the visible task. The invisible work disappears.

There's also the Office Space problem. Tom Smykowski's job, taking specs from customers to engineers, exists because two groups that should talk to each other don't. An AI agent doing that job faster doesn't fix the dysfunction. It makes the dysfunction cheaper to maintain, which means nobody will ever fix it.

These problems compound with the pricing problem. You're losing hidden value and underestimating the true cost of the replacement.

The enterprise implementation landscape has no map

I've spent my career securing technology for large enterprises. The current state of AI adoption is messy in ways the hype cycle doesn't cover.

95% of enterprise GenAI pilots fail to deliver measurable ROI. AI startups fold at a 90% rate. Every procurement and security team I talk to is solving the same problems from scratch because there are no settled implementation standards. If you build on a startup's tooling and that startup folds (the statistically likely outcome), you're doing a rip-and-replace on a system your organization now depends on.

Even the frontier labs present risk. What does "enterprise support" look like from a company projecting $74 billion in operating losses for 2028? When cloud computing was at this stage, at least the major providers had predictable business models. In the AI market, even the leaders haven't proven theirs work at scale.

Adopt aggressively, commit cautiously

None of this means don't use AI. Sitting this out has its own costs. But there's a difference between using a technology and betting your operations on its current pricing, providers, and implementation patterns all remaining stable.

Use everything, depend on nothing you can't replace. Build provider independence into your architecture. AWS Bedrock's Converse API lets you switch between foundation models with a parameter change. That's an architectural pattern, not a vendor recommendation. The principle is abstraction layers that let you leave without rebuilding.

Apply the Doorman test to every efficiency decision: are you automating a task, or destroying a capability? Run a 3x test on every AI dependency: what happens if the price triples or the provider disappears? Write every business case assuming current pricing is a promotional rate. Because it is.

The dot-com era didn't punish people for using the internet

The dot-com correction didn't kill the internet. It killed commitments that couldn't survive the transition from speculative pricing to real economics. The companies that signed exclusive deals with Yahoo in 1999 got burned. So did the companies that sat it out and decided the internet was a fad.

Imperfect action beats inaction. The companies that came out of the dot-com era strongest moved early and built to survive the correction. They tried things, kept what worked, dropped what didn't, and never locked themselves to a single provider or architecture.

AI will have its Googles and its Yahoos. Build so you benefit either way.

References

Rory Sutherland, Alchemy (2019) — the Doorman Fallacy
Cory Doctorow, "Enshittification" (2023) — platform decay as structural pattern
Reid Hoffman and Chris Yeh, Blitzscaling (2018) — subsidized market capture
Fast Company / Wall Street Journal — OpenAI and Anthropic financial projections (2026)
HSBC Global Investment Research — OpenAI funding shortfall analysis (2025)
MIT FutureTech — 95% GenAI pilot failure rate (2025)
National Employment Law Project — Uber post-IPO pricing data (2025)

Overmatch, Not Obsolescence: How to Think About AI and the Security Operations Fight

TL;DR: AI gives attackers near-term advantage. The response is containment architecture, not capability matching. Long-term the economics favor defenders. Getting there is the problem.

There are two ways to be wrong about AI and security. The first is panic: AI makes defenders obsolete, the game is over, buy something. The second is cheerleading: AI is the great equalizer, defenders finally have the tools to win. Both framings share the same flaw. They treat this as a question about technology instead of a question about competitive advantage in a specific operational environment, at a specific moment in time.

The military has a cleaner vocabulary for this. Technological overmatch describes a condition where one capability dominates another in a given context. It is not the same as obsolescence. A weapon system isn't obsolete until it can no longer generate effects on the enemy. Until that point, it may be outmatched in certain conditions while retaining decisive advantage in others. GPS jamming doesn't make aircraft obsolete. It degrades a capability in a specific environment and forces adaptation. The aircraft still flies.

Defenders are not obsolete. In specific conditions, right now, they are outmatched. Those are different problems requiring different responses.

Security has always been a time equation

In 1998, P.D. Herrmann formalized what practitioners already knew: a system is secure only if the time required to breach it exceeds the time required to detect and respond. Written as P > D+R, the model strips the problem to its variables. You win by making P large, D+R small, or both.

SOCs have been measuring this for years: mean time to detect, mean time to respond and contain. The distribution isn't normal, and that matters. Median performance tells you about the routine. P95 tells you about the stress cases. Maximum tells you about the incidents that actually end careers. Executives fixate on the max, and they're right to: that's where you actually lose.

Boyd's OODA loop maps directly onto this. The side that cycles through Observe, Orient, Decide, Act faster than the other forces the slower side into a permanent reactive posture. Boyd developed the framework to explain air combat; it applies without modification to a SOC managing an active intrusion. The attacker observes your environment, orients to your defenses, decides on a path, and acts. You observe their activity, orient your analysts, decide on a response, and act. Whoever completes that cycle faster controls the tempo.

AI compresses attacker cycle time. That is the actual problem. Not obsolescence. The clock runs faster, and the current D+R side of the equation wasn't built for the new speed.

Two types of attacker, one collapsing cost curve

Threat actors don't form a single population, and the distinctions matter because the risk calculus is different.

Commodity attackers — ransomware crews, initial access brokers, smash-and-grab operations — optimize for volume and speed. They burn through targets quickly, accept high noise levels, and profit from scale. A technique that works on 3% of targets is viable if you can run it against a hundred thousand of them before defenders respond.

APT actors operate on different economics. Nation-state groups and sophisticated criminal organizations running long-term campaigns have historically imposed their own discipline. Burning a novel exploit or a carefully developed tradecraft chain has replacement cost: time, money, and exposure. A zero-day used is a zero-day burned. That cost created behavioral constraints. Low-and-slow isn't just preference; for a capable actor protecting a valuable toolkit, it was the economically rational choice.

AI collapses that cost curve. When generating novel attack variants, rewriting signatures, and chaining techniques becomes cheap, the economic signal that enforced APT restraint disappears. The actor who previously ran a six-month campaign with careful operational security now has less reason for that care, because the replacement pipeline is cheaper. At the same time, commodity actors get faster, louder, and more capable.

The behavioral gap between disciplined APT and noisy criminal narrows. Infection rate accelerates across both populations simultaneously. More actors, lower barrier, faster iteration. The exposure window between a technique's development and defenders building detection for it shrinks. The window between a vulnerability's disclosure and its weaponization shrinks faster. Both trends are moving in the wrong direction for defenders, and they are moving together.

Risk is threat times vulnerability times impact. AI is moving the threat variable for both populations at the same time.

Herd immunity is already failing

Patches are inoculation. Unpatched systems are exposed population. Herd immunity in public health requires sufficient vaccination coverage to prevent an outbreak from sustaining itself. The analogy holds in vulnerability management, with one important difference: the threshold for digital herd immunity is effectively 100%. A single exposed host in the right position can be the pivot point for a network-wide compromise.

AI-assisted exploitation lowers the cost of finding and weaponizing the stragglers: the unpatched hosts, the end-of-life systems, the forgotten internet-facing instances. It doesn't require novel tradecraft. It requires finding the exposed population and moving faster than the defender's detection cycle. The stragglers have always existed. What changes is how cheaply and quickly an attacker can enumerate and exploit them at scale.

Nothing is ever truly obsolete on an unpatched surface.

Cybersecurity has an unhealthy fixation on what's new. Detection engineering optimizes for known patterns. Threat intelligence leads with emerging techniques. Vendors sell novelty. That fixation creates a blind spot that unsophisticated actors — and AI-assisted chains — exploit without effort. A CVE from 2017, rewritten to look unfamiliar, still works on an unpatched host. The attacker doesn't need sophistication. They need to be faster than your patching cycle and find you before your detection logic has seen the variant.

The more capable version combines legacy techniques with novel ones deliberately. AI lowers the cost of that combination. Defenders aren't looking for old and new chained together. Detection logic tuned to known patterns misses the hybrid. The fixation on novelty is the exploit.

Herd immunity as a strategic posture will fail. The exposed population is too large. Patching cycles are too slow in aggregate. Accelerating attacker economics widen the exploitation window faster than ecosystem-wide patch adoption can close it. Outbreak containment is the more honest priority. You cannot reliably protect the herd. You can design enclaves that survive an outbreak.

The threat model most organizations are running is wrong.

The standard framing is crown jewels protection: identify the most valuable assets, build concentric defenses around them, prioritize access controls. It's a reasonable starting point and an incomplete one, because destructive attackers don't always want the jewels. They want leverage. They want the thing whose absence forces a public statement, halts revenue, or breaks trust with customers.

In a retail organization, that's rarely the intellectual property. It's the payment processing infrastructure. The inventory management system. The payroll platform. These aren't the assets that show up at the top of a data classification exercise. They're the ones that, unavailable for 72 hours, bring operations to their knees.

Business continuity experts already understand this. A mature retail operation runs blackout drills: can stores process payments when the network goes down? The answer has to be yes, by design, before the incident — not improvised during one. Security organizations need the equivalent. Not just "where are the crown jewels" but "what does the operation look like when the thing we didn't think mattered stops working."

Enclave design is the architectural response: isolated, continuity-capable segments of critical operations built to limit blast radius and preserve the ability to function through a compromise. It doesn't prevent intrusion. It changes what an attacker can accomplish once inside, and it preserves options for defenders when the containment decision has to be made under pressure.

The threat intel trap

Threat intelligence is supposed to shorten detection time by giving defenders advance knowledge of attacker tools, techniques, and infrastructure. The theory is sound. The operational reality is more complicated.

Most threat intelligence originates from incident response engagements. IR teams develop detailed knowledge of attacker behavior, tooling, and indicators during active investigations. That knowledge eventually makes its way to threat intelligence products, sharing platforms, and public reporting. In my experience on active IR engagements, the lag between what the response team knows and what reaches public reporting is typically 14 to 60 days. The most actionable context — the full attack chain, the victim environment details that explain why specific techniques were used — is frequently locked behind attorney-client privilege. What reaches defenders publicly is often a stripped indicator list without the context that would make it operationally useful. Many defenders consuming that list don't realize it originated in an IR engagement at all, let alone one that concluded weeks ago.

Indicators of compromise have real value, but that value is narrow and time-bounded. An IP address associated with C2 infrastructure is useful during the window when the threat actor is using it. After that window closes, the indicator becomes noise: a hit on a decommissioned server that now hosts something benign, or an address reused by a different actor entirely. Matching IOCs without understanding the attack chain and the relevant time window generates false positives. False positives are not neutral. They consume analyst capacity — the same capacity needed to investigate real detections.

AI-generated threat intelligence accelerates this problem. Volume increases. Vetting quality decreases. The flood of low-confidence indicators creates the environment where high-confidence signals get buried. More intelligence, operationalized poorly, contributes negative value at scale. The defenders who navigate this best treat threat intel as a quality problem, not a coverage problem. Fewer indicators, richer context, matched to the threat window — that is a detection program. Everything else is noise with a feed subscription attached to it.

Detection first, containment by design, response last

The sequence matters because the failure modes are different at each stage.

Detection is where AI assistance generates the most near-term value. Alert creation, detection rule development, automated triage of high-volume low-fidelity alerts — these are tasks where the cost of an AI error is bounded and recoverable. A false positive costs analyst time. A missed detection costs more, but detection is a probabilistic game; no program catches everything, and the goal is improving signal-to-noise over time. Removing humans from the parts of detection work they perform worst — repetitive triage, pattern matching across high-volume logs — is achievable now and worth pursuing.

Containment is a different problem. Containment decisions are business decisions. Isolating a compromised host sounds like a technical action. In practice it may mean taking a production system offline, interrupting a business process, or triggering a customer-visible outage. The tradeoffs — how much operational disruption is acceptable to limit a particular blast radius — require business context that most automated systems don't have and that most organizations haven't codified in a form that could be communicated to one. Until organizations develop frameworks for expressing their risk tolerance and operational priorities in terms an automated system can act on, human judgment belongs in the containment decision loop.

Response and recovery sit further down the same problem. Don't automate what you haven't learned to do well manually.

The enclave design principle connects here. Containment is easier when the architecture supports it — when critical functions are isolated enough that taking one segment offline doesn't cascade. Organizations that have done the continuity design work before an incident find their containment options are broader. The ones that haven't discover their options during the incident, which is the worst time for that assessment.

The transition window is the problem

The long-term economics of this fight probably favor defenders, modestly. Defensive advantages compound at scale in ways attacker advantages don't. Threat intelligence shared across an industry is harder to evade than intelligence held by a single organization. Detection logic developed against a technique and distributed broadly limits the return on that technique investment. Collective patch pressure, coordinated disclosure, and shared defensive tooling all benefit from network effects attackers can't easily replicate.

None of that is available right now at the fidelity required to close the gap AI is opening.

The transition window is the period between attacker tooling maturing and defender tooling catching up. During that window, attacker economics are ahead of the curve. Tradecraft is cheaper. Exploitation is faster. Detection logic is behind. Threat intel quality is degrading. Automated response isn't ready.

The organizations that come through this window intact won't be the ones that matched attacker capabilities feature for feature. They'll be the ones that made the unsexy investments: aggressive patch cycles, enclave architecture, disciplined threat intel programs, and detection programs built for quality over coverage. Those investments don't generate press releases. They generate survivability.

Outbreak containment is not a permanent posture. It is what you do to stay in the fight long enough for the structural advantages to materialize.

References

Herrmann, D.S. A Practical Guide to Security Engineering and Information Assurance. Auerbach Publications, 2002. (Time-Based Security model, P > D+R)
Boyd, John R. "Patterns of Conflict." Unpublished briefing, 1986. (OODA loop)
Merritt, James. "Are We Ever Truly Obsolete?" Readiness Nation, 2024. (Technological overmatch vs. obsolescence framework)
MITRE ATT&CK Framework. https://attack.mitre.org (TTP taxonomy referenced implicitly throughout)
Verizon Data Breach Investigations Report, annual. (Threat actor population data and dwell time statistics)

Tuesday, April 14, 2026

How Birds Live to Talk About It

Most mornings I walk my kids to school. Ten minutes, same route, same trees, same stretch of sky. We talk about everything, but mostly the plants and animals we see along the way. The birds became part of that conversation several years ago — my kids have been to Craig Caudill's nature observation classes with me, so we're not starting from scratch on the walk. We're comparing notes.

It's ten minutes where nobody is looking at a screen. I've come to think of it as the most useful part of the day.

The forest isn't quiet. You are the noise.

When most people walk into the woods, they notice how quiet it is. That silence feels like the natural state. It isn't.

What you're hearing is a broadcast interruption. The birds went quiet because you showed up.

Jon Young, in What the Robin Knows, describes what he calls the "language of the birds" — five distinct vocalizations that function less like music and more like a distributed reporting system. There's baseline song: the relaxed, territorial, everyday sound of a bird at ease. There's companion calling: keeping track of neighbors, maintaining contact across the canopy. And then there's alarm — sharp, directional, precise — a call that carries information about what kind of threat is approaching and from where.

When you walk into the woods, you don't hear an absence of birds. You hear birds who have already communicated your presence to each other and gone silent or moved off. You didn't sneak up on anything. The robin by the trailhead told the jays fifty yards ahead you were coming before you even registered the robin.

This is why your backyard birds are so loud, and why the same species feels invisible in the forest. In your yard, you're furniture. The birds have assessed you, categorized you as predictable, and mostly ignore you. In the woods, you're a stranger. You move wrong. You don't belong to the landscape yet. Everything you do is information about threat.

What birds talk about on the way to school

Jon Young calls it bird language, and the name is more literal than it sounds. Birds aren't just making noise. They're communicating specific information to specific audiences, and once you know what you're listening for, it stops being background sound and starts being a readable signal.

We started simple. What's the difference between a bird singing and a bird alarming? Singing is relaxed — territorial, social, easy. Alarm is sharp, often repeated, directional. Once you hear the difference, you can't unhear it. My kids caught on faster than I expected. Kids are good at this. They haven't yet learned to tune out the world.

You don't need a dedicated practice or a special location. The school walk works. A parking lot works. Any five minutes where you stop generating noise and start paying attention works. The birds are always talking. The question is whether you've learned enough of the vocabulary to follow along.

Birds know your face. That should change how you walk in the woods.

In studies of American crows, researchers wearing specific masks during banding operations found that crows who had been trapped and handled would alarm call at anyone wearing that mask — even years later, even in locations far from the original capture site. They had spread the information. Other crows who had never been trapped recognized and responded to the mask-wearers because they'd learned to from crows who had been.

Robins distinguish between predators by the type of alarm they issue. A ground predator gets a different call than a flying predator. The call carries information not just about the presence of danger but about its geometry — where it's coming from, how to respond. Other species key off these calls. A sharp alarm from a robin can flush birds across multiple species who've never directly seen the threat.

Think about the economics of that for a moment. A bird that sounds a false alarm loses a few seconds and some calories. A bird that misses a real threat loses everything. That asymmetry shapes the entire system — when the cost of a false positive is low and the cost of a false negative is fatal, you respond early and you respond loudly. Not because you're skittish, but because the math is unambiguous. Millions of years of pressure have built a threat response that is calibrated, not fearful.

And the response doesn't stop at the individual. When a robin alarms, it isn't just protecting itself. The alarm propagates — to the jays, to the thrushes, to species that may never have seen the specific threat the robin spotted. The individual cost of calling is small. The collective benefit is large. Every bird in the area gets the intelligence for free. The ones who act on it live. The ones who ignore it are eventually the ones who don't.

That's the system the title is pointing at. Birds live to talk about it because the talking is precisely what keeps them alive.

When you move through the woods, you're not moving through empty space that happens to contain animals. You're moving through an inhabited place that is actively tracking you and sharing that information in real time. Your presence creates a wake of disturbance that moves ahead of you and behind you and to either side.

Craig Caudill talks about this as reading the landscape. A good tracker doesn't just look for physical sign — a print in the mud, a bent stem, a tuft of hair on a branch. They listen to what the birds are doing, because the birds are reading the same landscape faster and with better senses. The birds are already doing the observation. Your job, at first, is just to understand what they're telling you.

Tracking is forensics. Just without a keyboard.

Tracking is the practice of reading physical evidence to reconstruct what happened in a place before you arrived. A track in soft ground tells you what animal passed, roughly how long ago, which direction, at what speed, and sometimes whether it was under stress. A pattern of beds in tall grass tells you how many deer, how they positioned themselves, whether they were alert or relaxed. Stripped bark on a sapling tells you a buck was here, roughly when, and something about its size.

This is evidence analysis. It requires patience, pattern recognition, and comfort with incomplete information. You're almost never certain. You're working with what was left behind by something that isn't there anymore, building a picture and holding it loosely.

If you spend your days doing digital forensics, incident response, log analysis, detection work — any of the jobs where you're reconstructing events from artifacts — this is the same work in a different medium. The difference is you're doing it outside, in quiet, with your hands, and you can't just run another query. You have to look harder.

I find that useful. Not because it makes me better at either one in some clever crossover way. But because working through a tracking problem outside uses enough of the same cognitive muscle that I come back to a screen feeling like I've been working on something real. The problems aren't interchangeable, but the patience is.

Go outside. The birds are already watching.

None of this requires gear or a destination. You don't need to be in old-growth forest. The birds in a suburban park are running the same system as the birds in the deep woods — same vocalizations, same alarm propagation, same individual recognition. The landscape is smaller but the language is identical.

What it requires is attention. Specifically, the willingness to be still and quiet long enough that the world stops treating you as an interruption.

Start with the question my kids ask on the walk: what is that bird trying to say? That question is enough to get started. After a while you'll start noticing which direction the alarm is pointing, and then which species is relaying it, and then what that combination usually means about what's moving through the area.

At some point the birds will stop treating you like an event. When that happens, you'll realize you stopped seeing birds as a category too. You'll know that this towhee and that robin live here. They don't fly as far away from you as other birds do. They start to feel like acquaintances — and then friends.

That's worth ten minutes of your morning.

References:

Jon Young, What the Robin Knows: How Birds Reveal the Secrets of the Natural World (2012)
Craig Caudill / Nature Reliance School — naturerelianceschool.com
Georgia Bushcraft — georgiabushcraft.com

Autonomic Security: Stop Waiting for AI to Save Your SOC

The Adversarial Podcast's RSA episode is worth your time — CISOs talking candidly about autonomic security and where the industry needs to go. It got me thinking: if our CISOs are ready to have this conversation, how do we get our SOCs ready to meet the challenge?

This is my take on that question.

What autonomic security actually means

Your autonomic nervous system keeps you alive without asking permission. Heart rate, immune response, reflexes — they don't wait for a conscious decision. They execute on signal.

Autonomic security is the same idea: security responses that execute on policy without requiring a human decision at the moment they fire. This is not the same as autonomous security — AI making novel judgment calls in novel situations. Autonomic security executes well-defined responses to well-understood conditions. The question isn't whether the AI is ready. It's whether your organization is structured to act.

This is not a futures concept. It's a description of what your team should already be doing with tools they already have.

We've been doing this for 40 years

Antivirus has been quarantining files without asking since 1987. Intrusion prevention systems have been dropping packets inline since the mid-2000s. EDR kills processes autonomously — nobody files a change request first. Okta and Entra block or step up authentication on probabilistic risk signals right now, with no human in that loop.

All of these act on non-deterministic intelligence. We accepted that tradeoff at the endpoint and perimeter because the blast radius was bounded and the action space was understood.

The SOC has never been granted the same latitude. That's a leadership decision, not a technology constraint.

There's a good version of this and a bad version. Good security is responsive and proportionate — it acts fast and it knows enough about your users and assets to act intelligently. Bad security builds walls that valid business functions quietly route around. The difference is context, not capability.

A throwback: we already answered the false positive objection

When IPS was displanting IDS in the mid-2000s, the resistance was identical to what you hear today against agentic containment: what if it blocks something legitimate?

Here's the counterintuitive finding from that era: tolerance for IPS false positives was higher than tolerance for IDS false positives — not lower.

An IDS false positive means an analyst spent time triaging an alert on traffic that was benign. Wasted time, and the attack may still be running. An IPS false positive means a legitimate connection got blocked. Disruptive, but cheap: restore access, done, move on.

Which type of false positive is cheaper? The math favors action.

We settled this question twenty years ago. IPS became standard NGFW furniture within a decade. We are re-litigating a closed argument.

What's actually in the way

We never stopped treating every case as a snowflake

SOAR promised automation. Most implementations delivered expensive alert routing with a human checkpoint on every node. The technology wasn't the problem — the culture was. Playbooks require repetition to build confidence, and teams never let them run enough to develop that confidence. Every alert got individualized treatment not because it warranted it, but because nobody trusted the playbook.

At triage the action space feels unbounded and most options are undertested. So the default becomes: document and escalate. The playbook exists. Nobody trusts it. SOAR ends up automating ticket creation and nothing else.

This is a rehearsal problem and a permission problem, not a technology problem.

We fear what we don't know about our own environment

We don't fear the containment action. We fear the unknown downstream effect. Disabling a service account is trivially reversible. What isn't reversible is payroll failing at 2am because nobody mapped that account to a scheduled job.

The standard response is to go build a perfect CMDB before you automate anything. That project never finishes. Here's a better model: flip the default.

The SOC can and will touch anything not on the protected list. Business owners of critical applications get a defined window to communicate their special containment requirements. If they don't, they get the vanilla containment policy. The burden of knowing what's sensitive shifts to the people who actually know — the application owners — and off the security team trying to reverse-engineer dependencies from the outside.

This reframes the governance dynamic entirely. The SOC is no longer on the back foot trying to prove it's safe to act. The default is action. The business earns an exception by doing the work. If payroll breaks because finance never registered that service account as critical, that's not a security failure — the SOC acted on policy. The business opted into the default by not opting out.

The "tipping our hand" excuse is real but misapplied

There are situations where premature containment burns an investigation — targeted intrusions, sophisticated adversaries, high-value environments where watching the attacker move tells you something you need to know. That's legitimate tradecraft.

It describes a fraction of what most SOCs actually handle. Commodity attackers don't care what you know. They care how fast you move. Giving them rope costs more than the intelligence value of observation in the overwhelming majority of cases. We've cited a niche justification as general policy.

The accountability asymmetry

A containment action that causes a brief outage generates a ticket, a postmortem, and an angry VP. A failure to contain that enables lateral movement and exfiltration generates an incident report in which the analyst made a reasonable judgment call under uncertainty.

Your team has read this incentive structure correctly and behaved accordingly. Of course they're conservative. The career risk is asymmetric. This is a leadership problem — you set the incentive structure, and right now it rewards inaction.

The organizational boundary problem

Security operations often sits outside the production support chain of command. No change management authority, no on-call ownership. Reversible containment is technically low risk but organizationally it creates an IT incident that someone else has to resolve.

There's history here too. For a decade the SOC has been the first call on every IT outage and every "are we breached?" bridge call, spending hours proving a negative before anyone looks at the actual root cause. Of course teams are reluctant to build a direct line between their automation and the IT ticket queue. That's not obstruction — it's learned self-preservation.

SOC teams have grown comfortable distancing themselves from users and the production environment. Agentic tools won't fix this. They'll expose it.

The embarrassingly simple example

You don't need a new platform to start. A Claude agent, a SIEM query, a firewall API, and a written policy is enough to build the muscle.

claude -p "IP {ip} is triggering a brute force alert. 
Query the SIEM for legitimate traffic from this IP 
in the last 24 hours. If none exists, block it at 
the perimeter firewall and log your reasoning. 
If legitimate traffic exists, escalate for analyst review."

The agent checks context before it acts. It queries the SIEM, assesses whether the IP has any legitimate traffic history, makes a judgment, executes the block if appropriate, and logs its reasoning. Observe, assess, act.

This is not impressive. That's the point. The value isn't the technology — it's that your team just defined a policy, encoded a judgment into it, and executed a containment action without a committee meeting.

Start with the lowest blast radius, most reversible action you have. Run it. Build from there. The first autonomic action is the hardest one. Make it trivial on purpose.

The release valve your SOC needs

When automation blocks something, two questions hit the bridge call immediately: did security cause this outage? and are we breached? Your automation needs to answer both before anyone asks.

The block needs a paper trail that is instant, readable, and complete: what was detected, what was assessed, what action was taken, and why. Not a ticket — a log entry that surfaces immediately to whoever needs it.

The unblock path matters as much as the block. A SOC that responds to threat alerts in minutes may take days to respond to an IT operational ticket — those are different queues, different teams, different SLAs. If the release path for a blocked IP or disabled account routes through the helpdesk queue, the business remembers the slow unblock and forgets the fast detection.

Build the release valve into the automation itself. The SOC isn't hiding behind the agent — they're signing their name to it. A containment your team can't explain or can't reverse in 60 seconds isn't ready to be automated yet. One that comes with a full audit trail and an instant release path changes the SOC's relationship with the business: from the team that might have caused the outage to the team that prevented the breach and can prove it.

What you need to do

If you lead the SOC: You already have more authority than you're using. The blocker isn't the technology or the CISO — it's the absence of a written policy that tells your team what they're allowed to do autonomously and at what threshold. Write that policy. Run the playbooks. Own the production impact when something goes wrong, and expect to be supported when you do.

If you're the CISO: Define which containment actions your SOC can execute autonomously, at what confidence level, against what asset classes. Put it in writing and sign it. Then change the accountability structure — make inaction as reviewable as action. Your team will not act boldly if the only career risk is acting.

Both of you: establish the protected list and set a deadline for business owners to register their critical systems. Give them a reasonable window and a clear format. Whatever isn't on the list by the deadline gets the default containment policy. Run the process once, maintain it on a cadence, and stop waiting for a perfect CMDB that will never exist.

Demand better primitives from your vendors too. Action confidence scores, blast radius estimates, rollback APIs. Detection without actionability is a dashboard. If your vendors aren't exposing these, ask why.

What it looks like when it's working

The SOC defines policy and audits outcomes. It does not approve every action. Reversible, low-blast-radius containment executes automatically against clear signal. High-blast-radius or irreversible actions escalate with a recommendation attached, not a blank slate.

The team's job shifts from triage queue management to policy refinement and exception handling. The automation signs its name to every action it takes. The business has a release path that doesn't require working a ticket.

Your security program starts to behave like an immune system: fast, proportionate, and mostly invisible to the people it protects.

The AI isn't what's in the way. You are. That's actually good news — you can fix it.

Monday, April 13, 2026

Foundations: Know What You Own

Part 1 of the Foundations Series

Basic doesn't mean easy. It means fundamental and foundational. If we neglect our foundation our whole architecture crumbles.

TL;DR

Asset inventory is the most regulated, most recommended, and most under-built capability in security. Every framework tells you to do it. Almost nobody builds one that can actually support the weight of what comes next. This post walks through what a real asset inventory looks like at each stage of maturity, why the compliance version falls short, and where this needs to go as our environments fill up with non-human actors.

The Eye-Roll

If you've ever sat in a room where a regulator or auditor stressed the importance of maintaining an asset inventory, you've probably seen a senior practitioner's eyes glaze over. I've watched it happen with one of the best CISOs I've worked with. He's pushed mature security tooling into previously undefended M&A networks and found active breaches in the process. He doesn't need to be sold on asset inventory. He needs the recommendation to stop being so thin.

His frustration isn't that the guidance is wrong. It's that "maintain a list" doesn't begin to describe what he actually built, or what it took to make that list useful under pressure. The regulation gets people to the starting line. Everything after that is on you.

This post is an attempt to lay out the full distance. If you've been doing this long enough that the recommendation feels obvious, good. I'm putting structure around what you already know. If you're earlier in the journey, this is the map.

Why This Is Regulated

Every major security framework starts in the same place: you can't protect what you don't know about.

That's not a bumper sticker. It's the reason initial intrusions so often happen on the systems nobody was watching. The box that didn't get the EDR agent. The server a third party stood up and forgot about. The subnet that came over in an acquisition and never got folded into the security program. An unmonitored asset is a hiding place where an adversary can persist, and you can't monitor what isn't in your inventory.

This is why regulators care. They're trying to get organizations to the starting line. The problem is that most compliance implementations stop there.

The Compliance Version vs. The Operational Version

A compliance-driven asset inventory is a list. It has hostnames and maybe IP addresses. It gets updated when someone remembers to update it. It lives in a spreadsheet. It satisfies the auditor. In practice it's often not even one list: it's several lists in separate systems that don't talk to each other, each maintained by a different team with a different update cadence and a different definition of "asset."

That's crawl. That's the floor. And for a lot of organizations, that's where it stays, because the regulation doesn't describe what comes after.

The frustration practitioners feel with this isn't about the regulation being wrong. It's that a checkbox implementation doesn't serve as a foundation you can build on. It's a static artifact that answers one question ("do we have a list?") and can't answer any of the questions that actually matter during an incident, a vulnerability triage, or a coverage review.

Crawl, Walk, Run, Fly

Here's how I think about the maturity progression. Each level unlocks specific capabilities the one below it can't support.

Crawl

A list exists. You can count your hardware assets. You can hand it to an auditor and check the box.

What you can answer: "How many assets do we have?" (approximately)

What you can't answer: almost everything else.

Walk

The list is actively maintained. Every asset has an owner. During an incident, you can answer: who owns this system, what does it do, and who do I call. You're tracking lifecycle now, not just current state. When something gets decommissioned, you know when it happened and who did it. You know what you own now and what you've owned in the past.

This matters more than people think. If a corporate-branded laptop shows up on eBay, can you determine whether it was properly wiped and retired through your process? Or did it just vanish from the network one day and nobody followed up? That's an inventory maturity question, not a hardware disposal question.

At this level the inventory is a shared map. Incident responders and leadership are working from the same picture. You can scope lateral movement risk. You can identify system owners for notification. You're not running a scavenger hunt during a crisis.

Run

This is where the concept of "asset" expands well past hardware.

You're tracking user and non-user accounts. Service accounts. Identities. Virtual instances across cloud providers. Software bills of materials. And increasingly, AI agents: autonomous software actors that hold credentials and access systems on behalf of users or the organization.

Here's a number that should bother you: the average enterprise currently has an 82-to-1 ratio of non-human identities to human ones. That ratio is accelerating. Most asset inventories don't account for any of it.

At the run level your inventory also knows which security products have visibility on each asset and when they last checked in. First observed, last observed, by which tool. Coverage gaps are visible, not assumed. You can answer the question: if 15% of my assets quietly fell out of coverage, would I even notice?

That question is scarier than it sounds. Telemetry loss is usually noisy. Coverage erosion is silent.

Exposure surface is mapped. You know what's internet-facing, what's in a trusted enclave, what's reachable from where. Data classification is overlaid from DLP observations. Vulnerability management data is integrated where possible, though patch state and network topology remain ephemeral and hard to fully enumerate. That's worth naming honestly rather than pretending it's solved.

Fly

A unified, cross-environment source of truth. On-prem, AWS, Azure, GCP reconciled into one queryable system. The inventory is no longer a reference document. It's the decisioning layer underneath everything else.

Vulnerability prioritization is exposure-informed: an RCE in a trusted enclave with no inbound exposure is a different conversation than the same CVE on internet-facing attack surface. That decision requires deep asset knowledge that a CVSS score alone can't provide.

The inventory is structured for machine consumers, not just human ones. This is the part most people haven't thought about yet. As agentic response systems mature, they will need to query asset context at machine speed to make triage and containment decisions. If your inventory is a spreadsheet or a CMDB that requires a human to interpret, you've built a ceiling into your program that blocks the next generation of capability.

The Integration Problem

Here's a structural issue that nobody caused on purpose but everybody has to solve.

If you have workloads across on-prem infrastructure, AWS, Azure, and GCP, and no way to reconcile what lives where, how do you make informed decisions about coverage or risk? You can't. You're working from fragments.

SIEM and EDR platforms each maintain their own view of your environment. They're optimized for their own ecosystem, not for giving you a unified picture. The result is multiple partial inventories with no central authority. This isn't a vendor problem to complain about. It's an integration problem the customer owns. But it needs to be named, because it's the default state for most organizations and it undermines every capability that depends on knowing what you have.

Some gut-check questions:

If you assume you threw EDR on all your system builds but aren't running reports on agent health, you're in for a rude awakening. If you lost visibility to 10 or 20 percent of your assets in the estate, would you even notice? If you don't have a real asset count, how do you know how many agents are supposed to be there?

Non-Human Identities and AI Agents

The 82:1 ratio I mentioned earlier is just service accounts, API keys, tokens, and machine identities that already exist in most enterprises. AI agents are a new category on top of that.

These aren't hypothetical. Organizations are deploying autonomous agents that interact with production systems, make decisions, and hold real credentials. OWASP published the Agentic Top 10 in December 2025, and three of the top four risks center on identity, delegated trust, and tool access. The through-line to asset inventory is direct: agents mostly amplify existing vulnerabilities rather than creating new ones. If your inventory foundation is weak, agents inherit and multiply that weakness at machine speed.

An agent needs the same inventory rigor as any other identity. Who created it. What it can access. What tools and data sources it connects to. Who is accountable for its actions. When it should be decommissioned. If you can't answer those questions about your service accounts today, you definitely can't answer them about your AI agents. And the agent population is growing faster than the service account population ever did.

Where This Lands

The structure and quality of your asset inventory determines what you can build on top of it. Today that's human decision-making during incidents and vulnerability prioritization. Tomorrow it's autonomous systems that need structured, queryable context to operate safely.

Every framework starts with "know what you own." None of them describe the full journey. The regulator is trying to get you to the starting line. The rest of the distance is yours to cover.

Build the foundation like you're going to put weight on it. Because you are.

Appendix: Regulatory Landscape

This section is reference material for anyone who wants to trace the requirements back to their source.

NIST CSF 2.0 (ID.AM): The Identify function's Asset Management category covers hardware inventories (ID.AM-01), software and services (ID.AM-02), network data flows (ID.AM-03), supplier services (ID.AM-04), asset prioritization by criticality (ID.AM-05), and data inventories (ID.AM-07). The underlying NIST 800-53 control is CM-8, which at higher impact levels requires automated mechanisms for maintaining complete, accurate inventories and detecting unauthorized components. Framework-level guidance: tells you what to inventory but stays technology-neutral on how.

CIS Controls v8.1 (Controls 1 & 2): The most prescriptive of the major frameworks. Requires active management of all enterprise assets including those in cloud environments and those not under direct enterprise control. Defines six asset classes: Devices, Software, Data, Users, Network, and Documentation. Implementation Groups (IG1 through IG3) provide a maturity progression that loosely maps to crawl-walk-run. CIS also provides the clearest articulation of the adversary's perspective: attackers have demonstrated the ability, patience, and willingness to inventory and control enterprise assets at large scale to support their own objectives.

ISO 27001:2022 (Annex A 5.9, 5.10, 5.11): Requires organizations to develop and maintain an inventory of information and other associated assets, including assigned owners. Unique among major frameworks in explicitly requiring lifecycle tracking from creation through processing, storage, transmission, deletion, and destruction. Also addresses asset return upon termination of employment or contract (A.5.11), making it the only major framework that speaks directly to the decommissioning and disposal scenario.

PCI DSS v4.0 (Requirements 12.5.1, 2.4, 4.2.1.1, 6.3.2, 6.4.3, 9.9.1): Takes a scoping-first approach. Every system that stores, processes, or transmits cardholder data is in scope, along with anything on the same network without segmentation controls. PCI v4.0 expanded inventory requirements to include certificate inventories, bespoke and third-party software component inventories, and payment page script inventories. As of April 2025, organizations must also perform risk assessments on assets approaching end-of-life. PCI demonstrates the trajectory of what "asset inventory" means over time: it started as a hardware list and now covers certificates, code components, and scripts.

CISA BOD 23-01: The most operationally aggressive directive. Requires all Federal Civilian Executive Branch agencies to perform automated asset discovery every 7 days and initiate vulnerability enumeration every 14 days using privileged credentials. Demands on-demand asset discovery and vulnerability enumeration within 72 hours of a CISA request, with results due within 7 days. CISA explicitly states that continuous and comprehensive asset visibility is a basic precondition for managing cybersecurity risk. This directive comes closest to demanding queryable, responsive asset data rather than a static document updated quarterly.

The pattern: Every framework begins with the same premise. They all stop at different points on the maturity curve. NIST and ISO describe what should be inventoried. CIS adds how often and how to validate. PCI expands what counts as an asset. CISA BOD 23-01 pushes toward operational tempo and queryability. None of them reach the fly state described in this post.

Sunday, April 12, 2026

For Me This Is Tuesday

Glasswing is a good answer. It's just not the whole answer.

Before you read this: Start with the Project Glasswing announcement and the Anthropic red team's Mythos preview post. For technical grounding on what AI-assisted vuln research actually looks like in practice, Nicholas Carlini's Black-Hat LLMs talk at [un]prompted 2026 is worth your time. Once you've absorbed those, the Three Buddy Problem episode on Mythos and Glasswing is the most candid practitioner reaction I've heard, including some useful cold water on the framing.

When Anthropic dropped the Glasswing announcement and the Mythos red team preview, the reactions in security circles landed roughly where they always do. Some practitioners dismissed it. The threat landscape hasn't fundamentally changed, the vulnerabilities being automated weren't new, the attacker had tools before the model did. Others went the other direction, accepting exponential growth projections across every risk domain as license to argue for infinite spend against an invincible adversary.

"For me this is Tuesday."

I heard a version of this from a defender shortly after the announcement. Proud, confident, self-assured. And they're not entirely wrong. The threat landscape hasn't changed in kind. For defenders already guarding against well-resourced adversaries, the capabilities Mythos demonstrates were present in human hands well before GPT-3.5.

But in my experience responding to enterprise destructive attacks, that level of certainty about your own defenses was almost a guarantee we were about to find severe compromises or severe deficiencies. Defenders who are actually contending with their real environment tend to be humble. They know their specific blindspots. They can name the gaps they haven't closed yet.

The "this is Tuesday" defender is right about the vulnerabilities. They're wrong about the time.

What Glasswing is actually solving

Glasswing is a coordinated effort to use Mythos-class AI to find and patch vulnerabilities in critical software before adversaries can exploit them, autonomously, at scale, across codebases that have survived decades of human review and millions of automated tests. A 27-year-old OpenBSD vulnerability. A 16-year-old FFmpeg flaw that automated tooling had hit five million times without catching. Linux kernel privilege escalation via chained zero-days. These are real findings, and patching them before adversaries exploit them is unambiguously good.

The implicit theory of defense is: find and fix vulnerabilities faster than attackers can weaponize them and defenders win. That logic is sound at the software layer. The problem is it addresses only one leg of the race, and not the leg that's currently losing fastest.

The actual new thing is velocity at the operational layer

AI-enabled attack chains don't primarily create new vulnerability classes. What they compress is the interval between access and impact, and that interval was already collapsing before Mythos.

29 minutes: Average eCrime breakout time in 2025 (CrowdStrike). Fastest observed: 27 seconds.
5 days: Median intrusion-to-ransomware in 2025, down from 9 days the year before (Sophos).
89%: Year-over-year increase in AI-enabled adversary operations (CrowdStrike 2026 GTR).
~70 minutes: Initial infection to enterprise-wide ransomware deployment in one documented case (M-Trends 2026).

Microsoft's RSAC 2026 briefing documented AI embedded across the full attack lifecycle: reconnaissance, credential-lure generation, deepfake-assisted initial access, automated persistence, and in some cases automated ransom negotiation. The threat intelligence loop was already too slow for the fastest attackers. AI acceleration doesn't break a healthy loop. It exposes one that was already broken.

Patching the OpenBSD vulnerability is necessary. It does nothing about the attacker who has already achieved initial access and is operating in your environment faster than your SOC can triage an alert.

The patch is also a signal

There's a tension in the Glasswing framing worth naming. Mythos demonstrably works on source code. Autonomous exploitation of compiled binaries without source access remains a harder, unsolved problem, and that's a real constraint on the threat model. But it understates something practitioners who've done patch diffing will recognize immediately: the patch release is itself a signal. The moment a vendor ships a fix, an attacker doesn't need the original source. They need the diff. Reverse engineering what a patch corrected and working backward to the exploitable pre-patch state has been standard offensive tradecraft for years. Mythos-class capability on the offensive side compresses how fast that window gets worked.

Defenders who want to benefit from Glasswing need to treat the resulting patches differently than routine patch Tuesday updates. The vulnerability disclosure and the exploitation window now potentially overlap. Organizations should verify they have the internal capability to apply Glasswing-sourced patches on an emergency cadence, independent of normal change management cycles. If you can't move faster than an attacker can read a diff, the defensive advantage Glasswing promises doesn't fully materialize.

The gap Glasswing doesn't address

Glasswing represents a genuine coordination model: industry, government, and open-source maintainers aligned around a shared defensive capability. That structure is exactly right. What doesn't yet exist is anything like it at the operational layer. AI-enabled detection and response that can match the speed of AI-enabled attack chains, with coordinated accountability baked in.

What I'd actually want to exist, and largely doesn't yet, is a structural separation between the organizations defending you and the organizations stress-testing that defense. An AI-enabled response capability that can take autonomous action at machine speed needs to be held accountable by something that can attack at the same speed. A vendor assessing its own detection coverage is a conflict of interest at the worst possible moment. That accountability structure has to be designed in, not discovered after an incident.

Most organizations aren't close to this. The harder problem upstream of tooling is decision authority. Tactical containment decisions that currently route through change advisory boards at 2am will lose a race against a 27-second breakout. The defenders who navigate the next phase won't just have better software. They'll have worked out how to delegate consequential decisions at machine speed to people who are empowered to own the outcomes.

Why the FUD framing is also wrong

Accepting exponential projections across every risk domain and using them to justify infinite spend is the mirror image of "this is Tuesday." Both guarantee the status quo. Leaders who receive ungrounded threat assessments will rationally defer the decisions we're asking them to make until something more actionable appears. Our credibility as advisors depends on giving specific, bounded risk guidance, not gesturing at a scary horizon.

There's also a structural problem neither framing addresses: cyber attacks still operate in a near-consequence-free environment for most threat actors. In physical space we aren't protected primarily through hardening. We're protected because people who want to harm us have to weigh the cost of being caught. Public policy investment in using the same AI capabilities to expose threat actors to legal consequences would do more systemic good than any amount of private defensive spend. That's a long game, but it's the honest frame for why defenders are running a fundamentally asymmetric race.

What a defensible posture actually requires

Glasswing is a serious effort by serious people and it deserves a serious response, which means neither dismissal nor panic. The practitioners I trust most share a common intuition: security bugs are dense, not sparse. The more you look, the more you find. The right design assumption is that bugs are present, lateral movement pathways exist, and your architecture needs to limit blast radius accordingly. Zero-trust segmentation is exactly right for this environment, not because it prevents compromise, but because it makes the compromise slower and more detectable.

The harder work is the operational and organizational layer Glasswing doesn't address. The organizations that come out ahead won't just have better patch cadence. They'll have worked through what it means to delegate real authority at real speed and built the accountability structures to match.

References: Anthropic, "Project Glasswing," anthropic.com, April 2026. Anthropic, "Assessing Claude Mythos Preview's Cybersecurity Capabilities," red.anthropic.com, April 7, 2026. CrowdStrike, "2026 Global Threat Report," February 24, 2026. Mandiant, "M-Trends 2026 Report," March 2026. Microsoft Security Blog, "Threat Actor Abuse of AI Accelerates," RSAC 2026, April 2, 2026. Sophos, "The State of Ransomware 2025." Verizon, "2025 Data Breach Investigations Report."

Saturday, April 11, 2026

Lab Notes: Claude Code Session Logs as a Forensic Artifact

TL;DR;

Claude Code logs every agent action locally in structured JSONL transcripts. These are forensically valuable, generally unprotected, and your GRC and detection teams should know they exist.

Background

AI coding agents like Claude Code are becoming common in developer environments. Unlike a chat interface, these tools operate agentically — they execute bash commands, read and write files, and chain tool calls autonomously on behalf of the user. Users authorize this at session start, often broadly, and may not review every action taken.

This creates a non-repudiation problem. The user is responsible for agent actions, but awareness of specific actions may be limited or absent entirely. From a forensic and compliance standpoint that gap matters.

The Artifact

Claude Code writes a complete session transcript for every run to:

~/.claude/projects/<url-encoded-project-path>/sessions/<session-uuid>.jsonl
~/.claude/history.jsonl

Each record contains the timestamp, message type, tool name, exact command executed, full stdout/stderr, working directory, and token usage. This is not a summary — it is a full structured record of every action the agent took.

These logs exist by default. No configuration required.

Forensic Value

During triage, these transcripts can establish:

What commands were executed, in what order, and with what output
Which files were read or modified by the agent
Session start/end times and working directories
Whether the agent spawned subagents and what they did

The artifact is local, human-readable with basic JSON tooling, and does not require any cooperation from Anthropic or cloud infrastructure to collect.

The Problem

These logs have no integrity protection. There is no append-only mode, no tamper detection, and no access controls beyond standard filesystem permissions. An actor who has compromised a developer workstation can delete or modify them.

Recommendations

For DFIR, GRC and Detection Engineering teams:

Add ~/.claude/projects/ and ~/.claude/history.jsonl to your endpoint forensic triage collections alongside shell history and other user-space artifacts
Audit your AI tool inventory — Claude Code, Copilot, Cursor, and similar tools likely produce analogous artifacts. Verify what each logs and where
Require that commercial and in-house AI agent deployments log agent actions with sufficient detail for post-incident review, and that those logs ship to a protected destination
Baseline a SOC alert for deletion or bulk modification of agent log directories on developer endpoints — the signal-to-noise should be low and the fidelity high

Reference

Notebook for parsing Claude Code sessions into a forensic timeline: https://github.com/DFIR-DeRyke/dfir_oneoffs/blob/main/claude_timeline.ipynb

Show and Tell

A simple request in my lab executed 97 commands. The claude_timeline notebook was built to simplify human peer review of machine actions — here's a sample of what that output looks like: