Security OSAI AgentsIncident ResponseSecurity Engineering

The Security OS: The Layer That Will Define the Next Decade of Security

Venkat PothamsettyApril 28, 20263 min read
The Security OS: The Layer That Will Define the Next Decade of Security Banner Image

Until about six months ago, I was drowning in a team of security AI agents. I had built a whole pile of them, each with dozens of tools they could call.

My day-to-day was basically figuring out why agents had run, or why they hadn't, and whether what they found and did was actually legitimate. Most of my time went into tweaking agent logic and adjusting the agent loops themselves.

Then, in late summer last year, CLI-based tools started landing. Claude, Codex, Gemini CLI. We stopped worrying so much about agent orchestration and shifted focus to actually building out the security application logic.

In November, we got pulled into a complex incident response investigation for one of our customers. An employee had been hit by a phishing attack, and the attacker had moved laterally into the cloud environment and a few departmental applications. We needed to find not just the root cause but the full blast radius, so the customer could make informed decisions about who to notify and what to tell them. We had 48 hours.

I set up my usual 4x4 panel and started working through email logs, Azure logs, EDR logs, and resource change histories in Claude, trying to figure out when it all started. I was stiching together timelines, IP addresses, user actions, and resource changes by hand. That was the moment I started to feel where security is actually headed.

Each individual Claude and Codex CLI session was missing a few key things:

  • No awareness of the overall memory I was trying to build, or any sense of what had happened across the investigation as a whole.
  • No idea what the right next task was when a new session started, given what we had already found, what the known unknowns were, or what the unknown unknowns might be.
  • No best practices corpus to pull from, so there was no way to verify that every path an attacker could have taken had actually been checked.

So I was doing all of that manually. Constantly directing, redirecting, and re-grounding four by four "agents" that had no shared context.

That is when we started building the interface layer between the LLM brain and the human brain to solve exactly this. Working with customers and refining it internally, we started calling it a security operating system.

Because like an operating system, you shouldn't have to think about it.

It's an abstraction layer over the security stack, so I don't need to remember how each underlying tool works. I don't need to prod the agents about where to look. I don't need to remind them of best practices or feed them organizational context every single time.

That's what we call a Security Operating System, and we think it's what will define the next decade of security.

Continue the Conversation

See Transilience in Action

Review how cloud security and compliance workflows run in one place. Then compare with production case studies.

Share this post:

Recent Posts