At the Corner of Wit's End and Shady

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:

Friday, June 7, 2019

Lab Notes: Persistence and Privilege Elevation using the Powershell Profile

TL;DR;

A recent ESET blog post mentions a persistence technique I wasn't previously aware of that is in use by the Turla APT group. The technique leverages the PowerShell profile to sabotage PowerShell in a way that executes arbitrary code every time Powershell is launched, upon testing I've discovered this technique may also provide a low and slow vector to Domain Admin, and other privileged admin or services accounts by leveraging common flaws admin scripts, asset management systems, and enterprise detection and response tools. This post captures my observations working from Matt Nelson's 2014 blog post (Apologies to the researcher if there is prior art I'm unaware of at the time of this post)

Privilege Elevation - Local Admin to Sloppy Admin

Setup Requirements:

In my testing, you need local admin rights to create the global profile

$profile.AllUsersAllHosts
AKA C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1

This does not bypass Execution Policy (check with Get-ExecutionPolicy).

If it's set to AllSigned or Restricted, not only will the code not execute; the end user might notice a suspicious error message reminding them of the execution policy. (By default a Window 10 endpoint is Restricted)

A privileged user or preferably an automated task that runs PowerShell on the 0wned box with elevated domain privileges is needed. They also need to forget to pass –NoProfile flag when launching it (which seems like just about everything and everybody in a large enterprise)

Now any code you place in this global profile will be run by any user who launches PowerShell. We just decide what kind of PowerShell script we want our sloppy admin to execute, set our trap, and patiently wait.

As a POC I used 1 line of code:

Add-Content c:\windows\temp\test1.txt "$(Get-Date) Profile POC Launched by $(whoami)"

Within the hour a friendly enterprise asset management system ran my arbitrary code using SYSTEM, but with a phone call to IT and some trivial social engineering, this could have easily been one of the desktop admins.

Mitigation:

Similar to detecting persistence in the startup folder, if you can audit file writes and modifications to C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1 you can alert on this in real time. Most userbases will not be making frequent changes to this file, which should leave you with a low noise high fidelity alert
If you need another reason to preach the gospel of a restrictive PowerShell execution policy this may be it. Unfortunately, if your admins are using it already good luck telling them they can't use PowerShell
You can also audit to ensure any privileged accounts executing PowerShell on remote systems always invokes the –NoProfile command line argument

Persistence

For persistence, things are much simpler. Aforementioned mitigations 1 and 2 still apply, but the only requirement is the lax execution policy. Every user should have access to edit their own $profile and any code placed here will be executed anytime PowerShell is launched under that user context.

One Line POC:
Add-Content $profile "Invoke-Item C:\Windows\System32\calc.exe"

For detection, we need to monitor a few additional file locations, but the alert volume should still be manageable:

C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
$Home\[My ]Documents\WindowsPowerShell\Profile.ps1
$Home\[My ]Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
$PsHome\Profile.ps1
$PsHome\Microsoft.PowerShell_profile.ps1
$Home\[My ]Documents\PowerShell\Profile.ps1
$Home\[My ]Documents\PowerShell\Microsoft.PowerShell_profile.ps1

Resources:

Microsoft Documentation On Powershell Profiles https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles?view=powershell-6
Abusing Powershell Profiles https://enigma0x3.net/2014/06/16/abusing-powershell-profiles/
Turla Powershell Usage https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/

Tuesday, February 20, 2018

Asking Questions. A STORY FOR MOST PEOPLE

[The following is an excerpt from The Manufacturer and Builder Volume 0001 Issue 1 (January 1869). I came across this in my woodworking research, and want to preserve it here because its centrally relevant across all of the domains I'm interested in.]

Once there was a young man whose name was John. That is to say, not knowing what his name was, and taking all the chances. I think it was probably John. For the same reason I take the liberty of presuming that his other name was Smith. Having previously been a boy, like the generality of young men. John had learned during that period an art which was almost the only thing that distinguished him from other Johns. He knew how to ask questions; and the object of this brief sketch of his life is to show how he acquired this accomplishment, and what came of it.

He used to say that his father, who was a farmer gave him the first lessons in asking questions; and putting together what his father told him at different times, he compiled a set of rules on the subject which he showed to a Friend the other day, neatly written on the flyleaves of his pocket-diary. They were headed,

The Art of Asking Questions

Every man knows something that I do not know.
Every thing, living or inanimate, has something to tell me that I do not know.
It is better to ask questions of things than of men; but its better to ask men than not to ask at all.
Lazy questions, impertinent questions, and conceited questions are the greatest of nuisances. They are like conundrums without any answers - they tend to make men dislike all questions; and when asked of nature, they get no response from her whatever.
Asking questions is of no use, if a man forgets the replies.
People like to be asked, in the proper time and manner, concerning matters which they understand. When they refuse to satisfy such inquiries, it is generally because the matter is not their business, or they think it is none of mine.
Remembering a thing is not necessarily be living it. I will remember whatever is told to me by men or by nature ; but I will bear in mind that men may be mistaken, or that I myself may misunderstand both words and facts.
The way to remember the answer to any question is to associate it in the mind with other answers connected with the same subject. It is well, therefore, to follow one subject, if possible, until sufficient has been learned about it to be easily remembered; for the more one knows the more one can remember, while isolated facts soon get lost. As my father said, "Wholesale stores are the easiest to keep in order."
Never be ashamed not to know, but be ashamed not to learn.
Never pretend to know ; as for pretending to be ignorant, there is no danger of that, since all men are ignorant. Even in asking questions concerning the subjects which I have most carefully studied, I may truly say I desire to learn ; for I may have made mistakes or omissions in my study which another might correct. As my father said, "Judge Pickerell spent forty years in collecting coins, and found at last a coin that was not in his collection in the hands of a beggar, who had that and nothing else."
As my father said, "Every stone is a diamond unless it is not; therefore every stone may be a diamond, until you know it is not ; and in finding out that it is not a diamond, you may discover that it is something more useful."
As my father said, "A man who is forever asking and never answering is like the swamp in our forty-acre lot. You can't raise crops without rain on one hand and drainage on the other."

From the foregoing it will be seen that the elder Smith was a man of sense. Certainly his neighbors thought the same thing. Frequently the judge or the parson or the doctor would come riding by his farm, and the plain farmer would leave his plow and sit upon the rail fence, under the shadow of the great elm, whittling a stick, while they talked with him on various matters of politics or social management. It was noticeable that he seldom asked other people for their opinions, and they soon learned to be a little shy of offering any; for he was sure to reply, "Indeed, what makes you think so?" and that is a troublesome way of putting it. On the other hand, they were always anxious to get his opinions in exchange for their facts. As the judge remarked, "Farmer Smith's views are his own, and they are worth hearing. He doesn't think he is obliged to say something on every subject, whether he understands it or not; and when he does speak, he tells what he knows."

He was always particular to give the source of his knowledge. He would say, "I have observed," or "I have read" or "As far as I can judge, it seems to me," and the like. And when others contradicted him, he used to say, "I am very glad to hear your experience on that point, because it is different from mine. I will make note of that." After he died, they found among his papers a good many notes of this kind with the names of those who had given the information, and marked in the margin with different signs, indicated, according to a method of his own, which he never told any body, the degree of reliance which he thought was to be placed in the authors or their communications.

It must not be supposed that he gave his son John the above set of rules all at once, like a catechism. On the contrary, as I before hinted, he dropped them in the form of remarks, from time to time on appropriate occasions. On some of these occasions I shall give examples in the next chapter. It may be thought that I am writing the life of the wrong Smith. In fact the father and not the son would be my hero, but for the fact that John's greater opportunities, and advantages enabled him to make a more brilliant career outwardly; and the full fruit of the old man's system, as well as the reward for his patience and a good sense, was realized in the success of his son. After all, however, if health and virtue and good nature and a well-trained mind be success, then old Smith achieved it.