There was a concept at Google that I always had mixed feelings about. It is called the “No Heroes” rule1, and the argument goes like this: When an individual has to do a heroic task (ex: work 18 hours straight to prevent an outage) that effort is masking a systemic and institutional gap. The right response is to fix the system so heroism becomes unnecessary. In a mature, high performing engineering org, there should be no heroes.

No Heroes is generally the correct engineering doctrine in a mature organization. But I believe it is wrong as a theory of how institutions actually get things done, and is wrong about human nature.

Charlie Munger once described Google’s headquarters as a “very rich kindergarten.” Munching on snacks in the micro-kitchen, I couldn’t help but feel I was getting soft, and that the organization itself was getting soft. No Heroes removes the veneration of going hard, which over time selects for a different kind of employee. Google is an unusual place and was a privilege to work at, but a No Heroes ethos paired with a culture of comfort gets dangerous the moment the org has to get medieval and go from 0 to 1.

Even inside Google, I was often surprised to find that one engineer happened to know everything about a system and was the major driving force behind it. Most progress, even inside large institutions, is made by one person with the drive and skill to pull it off. The xkcd “Dependency” comic about modern infrastructure resting on “a project some random person in Nebraska has been thanklessly maintaining since 2003” is a joke and also true.

This is the double-edged sword. There is a concept I came across recently called the Bus Factor. It refers to the number of people who would need to disappear (get hit by a bus) before a project loses enough critical knowledge to continue. A 2015 study found that for 64% of the top 133 GitHub projects, the Bus Factor was below 22. Heroism without institutional backing produces fragility.

I am in many ways amenable to the Great Man of History theory. It is hard to operate in the startup world without believing at least parts of it. The founder is that great (wo)man, single-handedly pulling the company, and sometimes the world, along into something generational.

Startups, and the startup mindset, are organized entirely around heroism. It is all “cracked 10x engineers” and going Founder Mode, and it really does take a uniquely visionary and gritty individual to go from 0 to 1. The cost is that 24/7 heroism is often unsustainable, and a major cause of startup death is the founder giving up. Startups need at least some institutional scaffolding so that the company can survive a key person leaving. But Brian Chesky’s vision of Founder Mode is essentially that the founder-as-hero archetype should never end, even as a startup scales up even into IPO. So in the vision of Founder Mode, the company is the founder. The founder absolutely should understand the product best, but the same instinct, taken too far, can produce tyrannical micromanagement and cults of personality.

The military is a great example of holding “No Heroes” and “celebration of heroes” in tension simultaneously. Individuals join as they are, and the institution forges them into a disciplined whole greater than the sum of its parts. Individuals are made interchangeable, and the institution is designed to keep functioning regardless of who fills any one role. And yet military history is overwhelmingly a history of named individuals doing heroic, extraordinary things in service of the mission. Nobody gets a Medal of Honor in a mission where everything goes to plan. We have after action reports to root out systemic failures and learn from mistakes, but we also celebrate, honor, and encourage heroic acts of service.

Heroism and institution are complementary and must be calibrated to meet the moment. Google could probably use a few more heroes (Sergey Brin getting back in the weeds to build agentic coding is a great example of this). Open source probably needs fewer heroes and more structural support, so that critical infrastructure does not rest on one burned out maintainer. Startups could use more institutional scaffolding, so founders can survive long enough to build something durable. I do not have a clean rule for which mode any given organization needs. The hard judgement call is knowing which one your organization needs more of, and when.

Most of the chatter is about speed. Speed to vuln discovery and exploitation, versus speed of patching and responding. That’s definitely a problem which needs to be solved, but I want to take this in a slightly different direction and focus on the asymmetric cost of inference.

Mythos is genuinely, concerningly capable, and my assumption is other labs will likely close the gap in 3–6 months, and open source possibly in 12 (don’t hold me to this prediction). Mythos is also rumored to be extremely large, expensive to train, and expensive to run. Now that frontier models are better than humans at offensive cyber tasks, the bottleneck stops being cyber talent and becomes industrial capacity.

As these agents run 24/7/365, cyberwarfare starts to look like a contest of which nation can sustain the most datacenters and gigawatts.

This means the defender’s response isn’t just to “use AI too”. It’s to balance out the compute cost ratio.

How much inference does it take for an offensive AI agent to go from an external-facing web app to domain admin? My (somewhat) educated guesstimate: not that high. And it’s going to take significantly more inference and compute to ingest logs from each endpoint, correlate them, get an agent to triage, and then do the remediation. From an inference standpoint, defense (as we currently do it with the SOC model) is probably more expensive out of the gate.

The analogy I like to work with is that of kinetic air defense. Patriot PAC-3 interceptors run about $4 million each, while Shahed drones cost roughly $20,000 to $50,000. Not to mention production time and industrial capacity limitations. Whoever forces the other side into the wrong side of the cost curve wins the war of attrition.

AI-enabled cyber is heading to the same place. “Can the model do it” will no longer be the question - we know it can, and if it’s can’t it’ll probably be able to in the next 12 months. The question I’m most interested in now: what’s the cost ratio, per campaign, per target, between the cheapest offensive capability and the cheapest defense that neutralizes it?

If you’re building toward structurally cheaper defensive inference - I’d love to hear from you!

Anyone who has built or worked with AI agents knows they can be superhuman yet also quite dumb. They depend on the right prompting, context management, tool calling, and task planning to function at all. Of course, there are brilliant engineers working nonstop to close these gaps, and I believe they will. But the architectural properties of LLM-based agents introduce inherent weaknesses that human attackers don’t have. Defenders should exploit them.

The MITRE ATLAS framework maps adversarial attacks against AI systems. It’s a threat model for defending your own AI. But I propose flipping it - use it as a guide for how to attack agents trying to attack your network.

A few examples:

• Prompt Injection -> Anything an attacker pipes into an LLM should be contested ground. Logs, error messages, READMEs, API responses, etc. Embed injections everywhere. Make attackers second-guess every bit of context they ingest.

• Memory and State Corruption -> Agents with persistent memory or long-running task state are especially fragile. Honeypots and canaries have always existed, but now they can be tuned to exploit how agents plan. Corrupt the planning stage, and you’ve derailed every downstream step. You’ll also be forcing agents to burn tokens chasing fake leads.

• Tool Poisoning -> Attackers living off the land rely on existing binaries. Agents trust the outputs of the tools they call. Poison those outputs (in a way that doesn’t deceive legitimate users).

• Context Window Flooding -> What if we weaponized the “Lost in the Middle” problem? LLMs reliably lose track of information buried in long contexts. Flood the zone.

• Corrupt the Validation Loop -> Well-built agents usually have self-checks, such as running tests or validating against initial requirements. If tests pass, an agent usually thinks it’s all good and moves on to the next task.

You may notice that much of this centers around deception! More on that in a future piece.

I believe the future of cyber defense is not to replicate the existing SOC structure with AI agents. It’s to build solutions that asymmetrically impose costs on attackers, however they evolve.

Now is not the time to mope about how AI-enabled attackers are going to go so much faster, and find so many more vulns, and move at such scale - we know they will. Agents introduce a whole class of vulnerabilities that humans don’t have. The goal isn’t perfect deception or stopping agents completely. It’s about impeding every step and imposing costs, making agentic attackers distrust their own decisions at every stage of the kill chain.

—

If you are building solutions to attack AI agents (for defense), I want to hear from you!

As a former professional software engineer, it’s insane just how much the profession has changed in the past 2 years, and especially in the past few months. 2 years ago I was still hand-coding with VSCode, augmented with a little line completion. 1 year ago I was using Cursor with GPT 4.5, letting it a file or two at a time, reading and reviewing all code the AI produced. Today I’m a whole lot more hands off.

It’s gone from me only trusting AI to complete single lines of code, to me trusting AI to write functions, to me trusting AI to write files, to me trusting AI to write entire features (and getting AI to review the code also).

I’ve been experimenting heavily with (semi) long-running coding agents lately, and my current max is around 5 concurrent agents. There are two big bottlenecks:

• My own mental context window. I could be using an orchestrator agent with a kanban board to manage those agents, but I actually want to be hands on with the business logic. After 5 agents, I can no longer keep track of what’s going on. Possibly a skill issue.

• My current codebases aren’t big enough for that many agents to work discrete features without bumping into each other and causing merge conflicts.

My current setup

Given the speed of changes in the devtools ecosystem, I’ve been tweaking my coding setup weekly. This is my current setup as of April 2026:

• Conductor for managing agents (free)

  • As much as I like iTerm + Tmux, Conductor is a level up for managing agents. The sandboxing makes it much easier to manage multiple sessions. I would find it much much harder to manage multiple agents if not for Conductor.

• Claude Code (Opus 4.7) – Max Plan 5x ($100 per month)

  • It’s great - I don’t have much to add about Claude Code that hasn’t already been written.

  • Claude Design is shockingly good also. Highly recommend. I’m no designer, but I’ve been using it a lot ever since it came out.

• Codex (GPT 5.4) – ChatGPT Plus Plan ($20 per month)

  • I use a mix of both Claude Code and Codex. I originally started using Codex because I had been hitting Claude Code usage limits (I’m on the Max 5x plan), but then started to actually like it. Claude Code is still my primary coding agent, but I still use Codex to review the code that Claude Code produces. I don’t have strong opinions about the pros and cons of Codex versus Claude Code. I find them to be borderline interchangeable.

• Gstack setup for Claude Code (free, thanks Garry Tan)

  • I opted to use Gstack rather than building out many of my own Skills because I’m probably not going to put in the cycles to maintain them just for myself, and I’m personally probably better off deferring to the best practices built up by the community.

  • Gstack forces clarifying questions upfront. I wish this was the default for coding agents - force more clarifying questions, so that the agents don’t try to overcomplicate every feature.

  • The /office-hours skill pretty neat.

  • Gstack adds a lot of input tokens into the context window. Sometimes the features are a bit overkill for me, and I only use a handful of the skills.

  • Claude Design removes the need for a lot of the Gstack design skills.

• If I’m using local models, I’ve been using Ollama and mainly Qwen 3.5 9b and Gemma 4. I rarely use local open source models though because they’re too dumb for most of my use cases, and too slow running on my Macbook.

Is the code quality any good?

As for the quality of the code actually generated, it’s not terrible. I still toss out a significant amount of code, and refactor frequently, but it’s all workable. I rarely if ever find myself editing code by hand, which is pretty different from one year ago, back when I was using Cursor.

It's still very much a work in progress and I fully anticipate changing things as the space evolves on a daily basis.

On the Jane Street trading floor, every algorithm had its own sound. Walking the floor was said to be like being in an arcade, a cacophony of soundbites constantly going off, each corresponding with an issue that needed to be addressed. Traders didn’t just look at dashboards; they experienced rhythms and could identify when something was going wrong, not just from looking at a monitor, but by hearing it in real time.

I love a good pewpew map, even though they’re usually pretty useless and completely inaccurate representations of threats. But what if we applied the Jane Street concept more seriously to the SOC?

Imagine if every detection rule had its own sound. You would hear it every time it fired. (A badly tuned detection rule would immediately become unbearably annoying – a great motivator for reducing false positives.) An analyst would know their network was being attacked not by squinting at a Splunk dashboard, but by the specific sonic sequence of a kill chain unfolding in the room around them. 

Consider if you could taste the bitterness of Kerberrosting, or hear the rhythm of SMB enumeration in progress. While this sounds absurd on the surface, I would posit that it is more absurd that we have compressed all threat detection into a 2D screen, ignoring all senses beyond sight, ignoring the full human nervous system’s analytical capabilities, and hampering our ability to develop intuition quickly.

A couple of years ago, I worked as a deckhand on the Götheborg of Sweden, an exact wooden replica of an 18th-century East Indiaman tall ship. My time on the ship reminded me how many English phrases are maritime metaphors. Now, when someone says “all hands on deck”, I can physically feel myself awoken from my hammock and rushing to get on deck in the cold and wind to push a capstan along with 10 other crewmates, just to tack. I don’t conceptually just know the phrase. I know how it feels. Experience is a deeper level of understanding. With a multisensory SOC, an analyst’s understanding of an attack would go from conceptual to experiential. This is the same reason hospital monitors beep, and airplanes have stall horns.

I think a lot about what it means to be a good analyst and how we develop the next generation to be even greater. In the book Thinking, Fast and Slow, author Daniel Kahneman provides an anecdote about how the Israeli military conducted interviews. There would be checklists to follow, but the best interviewers would follow the list, then close their notebooks and stop, sensing how they felt in their gut. This combination of process and an educated gut was where they found the best judgments were made.

The AI native SOC is coming. Detection, triage, and most tier-one analysis will soon (if it hasn’t already) be fully automated by agents. If we don’t intentionally train the next generation of cybersecurity professionals, we’ll wake up in a decade wondering where all the mid-level talent went. 

So how do we build up gut-level experience in the next generation of cybersecurity professionals? I believe it will be through building something like a Multisensory SOC. A system that unlocks the full human sensory analytical capacity and compresses the timeline for turning conceptual knowledge into experience.

As models continue to improve, meeting and exceeding human capabilities in cybersecurity (just look at Anthropic’s Mythos Preview), I increasingly believe the only moat for humans is to lean into being human. It’s our feelings, it’s our intuitions, it’s our gut, the things AI will (hopefully) never be able to replace.

—

I’m increasingly interested in people who are building things to unlock multisensory experiences, bringing about the physical manifestation of the digital. If you’re building in this space, I want to hear from you.

—

Footnotes:

1. Shoutout to my friend Sam for originally giving me the idea about Jane Street. This post is inspired by his white boarding.

2. Going Infinite by Michael Lewis has a great recounting of the Jane Street trading floor

3. My Thinking, Fast and Slow anecdote is an extremely boiled-down summary. I highly recommend reading the book.

4. A sound-based network monitoring system was tested in 2000 by two researchers (Michael Gilfix & Alva Couch) at Tufts University. They called it “Peep: The Network Auralizer”. It never got beyond the experimental phase.

If you delete a file on macOS and empty the Trash, your Mac still remembers exactly what it was called and where it lived.

.DS_Store files are one of my favorite forensic artifacts. They're niche, kind of weird, and pack a surprising amount of forensically useful information.

To most of my software engineer friends, ".DS_Store" is just a line you put in your .gitignore. Under the hood, there's a lot more going on if you know what you're looking for!

Quick backgrounder: the .DS_Store (Desktop Services Store) file is a hidden binary that macOS Finder creates in every directory you open. It stores display preferences, icon positions, window size, view mode, sort order and uses a proprietary format and stores records in a B-tree.

Lots of awesome reverse engineering work was done over a decade ago on the file type by Mark Mentovai and Wim Lewis and I wouldn't have understood how it works without first reading their posts.

Why should forensic investigators care?

• The .DS_Store file's existence proves someone browsed that folder in Finder

• Filenames persist in .DS_Store even after the files are deleted until the system reboots (I still need to do a bit more testing on how long the deleted files last - it may depend on macOS version)

• Trash put-back records store where trashed files originally came from, surviving even after the Trash is emptied

• Timestamps and file sizes are recorded at the time Finder indexed them

• If someone deletes a sensitive file and empties their Trash, the .DS_Store in ~/.Trash can still tell you what the file was called and exactly where it lived before deletion

Writing a .DS_Store parser

Without being properly parsed, the .DS_Store file is pretty useless. I built “ds-store-parser” (with help from Claude Code, of course!) to turn the .DS_Store binary into accessible and useful forensic information.

It's a Python CLI tool using only the standard library, Python 3.10+. It reads the raw binary, decodes the record types, and outputs clean CSV or JSON. One row per file, with human-readable columns for everything (while maintaining the raw data). I validated it against 368 real .DS_Store files from my MacBook.

Next time you push to GitHub, make sure you’re not adding a .DS_Store file! It is quietly leaking your directory structure and filenames to anyone who knows how to parse it.

Check out the parser on my Github: https://github.com/jonathanlooi/ds-store-parser

Your Mac (sort of) keeps a record of every file you’ve downloaded from the internet.

It’s stored in a SQLite database called Quarantine Events V2 (located at ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2).

But why is macOS collecting all this information in the first place?

Mac uses this database to warn users before opening potentially malicious files downloaded from the internet. It’s the feature that gives you the notifications asking: “[downloaded app] is an app created by the app [source app]. Are you sure you want to open it?”

macOS has had a quarantine system since Leopard (10.5). Gatekeeper, the built-in security feature that verifies that a downloaded app is from an identified developer (code signing) and has been submitted to Apple for malware scanning (notarization), builds on top of this quarantine system. When a quarantine-aware app like Safari, Chrome, or Mail downloads a file, macOS stamps it with a com.apple.quarantine attribute and logs the event in the QuarantineEventsV2 database.

The database schema includes: a UUID, timestamp, agent name (downloading application), bundle identifier, download URL, origin URL (the referring page), sender name/address (for email attachments), and a type number.

Notably absent is the actual filename. There is no column for it. The UUID ties to the extended attribute on the file, but once the file is deleted, that link is broken. You cannot recover the filename from this database alone. In practice, many fields are frequently empty. I queried my own Mac and reliably got timestamps and agent names. Origin URLs were populated for some entries, absent for others. Sender fields were almost never populated. Also, keep in mind that timestamps use Cocoa epoch (seconds since Jan 1, 2001). Add 978307200 to convert to Unix epoch.

So what is QuarantineEventsV2 actually good for?

• Corroboration. Cross-reference quarantine timestamps with browser history, FSEvents, or Unified Logs to build a more complete timeline.

• Agent name analysis. LSQuarantineAgentName reliably identifies the downloading application. AirDrop transfers show up as sharingd.

• Persistence. macOS never cleans this database, even after files are deleted, Trash is emptied, and browser history is cleared.

Since this is just a SQLite database, you don’t need a custom parser! And for forensic workflows at scale, Velociraptor’s MacOS.System.QuarantineEvents artifact and Plaso’s ls_quarantine plugin already handle the parsing and timestamp conversion.

Try this on your own Mac:

sqlite3 -header -column ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 “SELECT datetime(LSQuarantineTimeStamp + 978307200, ‘unixepoch’) as download_time, LSQuarantineAgentName, LSQuarantineDataURLString FROM LSQuarantineEvent ORDER BY LSQuarantineTimeStamp DESC LIMIT 20"