The difference between useful SecOps agents and dangerous SecOps agents is the control plane around them.
The useful cost metric for an AI security agent is not cost per token. It is cost per defensible security outcome.
Half essay, half marginalia. Mostly about AI agents, security systems, the boring details that make products actually work, and what I've learned by writing it down. New entries land here when they're ready.
A curated reading path for recruiters, founders, CISOs, and engineering leaders who would like to understand how I approach AI-native cybersecurity, agentic SOC, SecOps platforms, and hands-on engineering leadership.
showing 42 published notes
The useful cost metric for an AI security agent is not cost per token. It is cost per defensible security outcome.
AI governance becomes useful when every principle has an owner, an engineering control, and evidence.
A SOC migration is an operating-model change disguised as a platform project.
The useful build-versus-buy question is not whether to buy an AI SOC. It is which layers create advantage and which create maintenance.
An AI SOC evaluation set should represent the decisions analysts face, not merely the questions models answer well.
In AI security SaaS, tenant isolation has to survive retrieval, memory, tools, traces, and every cache between them.
A security agent becomes dangerous through the combination of untrusted context, trusted tools, and borrowed authority.
A production AI security platform is an evidence and control system with models inside it.
An AI SOC should be measured by better security decisions and calmer operations, not by how many model calls it makes.
Agentic SOC strategy is not 'AI replaces analysts.' The real strategy is choosing a painful workflow, proving trust, and earning automation step by step.
A founding CTO in AI cybersecurity has to build the product, the trust system, the engineering culture, and the risk posture at the same time.
If I owned an AI security platform, I would build around evidence, controlled agency, analyst workflows, reliability, trust, and a team that can ship without losing judgment.
AI security demos are easy to like. Production systems need evidence, permissions, evals, observability, rollout discipline, and a plan for being wrong.
A practical interview loop for finding AI security leaders who can build systems, lead teams, reason about risk, and ship products analysts can trust.
An agentic SOC platform should be judged by the control system around the model, not by the confidence of the demo.
The fastest way to hire an AI security engineering leader is to stop interviewing only for management polish.
Builder-leader is the shortest phrase I have for the kind of cybersecurity engineering work I want to do next.
The difference between useful SecOps agents and dangerous SecOps agents is the control plane around them.
AI security platforms will not earn analyst trust by sounding fluent. They will earn trust by showing evidence.
The fastest way to evaluate an AI security engineering leader is to ask what they would change in the first 90 days.
If an AI security agent becomes part of the SOC workflow, it needs reliability engineering like any other production system.
Threat intelligence pipelines fail when they treat intelligence as a feed problem. The hard part is turning sources into evidence, context, and decisions.
Agentic SOC systems need memory, but not the soft kind. They need a structured graph of entities, evidence, relationships, and decisions.
Agentic incident response is not autonomous panic. It is structured delegation inside a response system that preserves evidence and keeps humans in control.
Modern intrusions often look like normal users doing abnormal things. That makes identity the center of the AI-native SOC.
An AI SOC agent should not graduate to production because it gave three impressive demos. It should graduate because it survived evaluation.
AI can help write detections, but detection engineering is still an evidence discipline, not a prompt trick.
Agentic AI in the SOC becomes dangerous when tools are treated like plugins instead of production security interfaces.
The best AI cybersecurity talk right now is not about replacing analysts. It is about rebuilding the SOC around evidence, workflow, trust, and controlled agentic systems, from someone who can build and lead the work.
Traditional security platforms were built around dashboards and queues. AI-native SecOps platforms need evidence, workflow memory, typed actions, guardrails, and analyst control.
Dark web exposure work is not just searching shady indexes. It is entity resolution, evidence handling, identity risk, source confidence, privacy discipline, and response orchestration.
Langflow makes AI workflow structure visible. Production engineering begins with deciding which responsibilities belong outside the graph.
Security investigations are not search problems. They are evidence problems. Deep research systems need retrieval, correlation, memory, provenance, and a refusal to invent confidence.
Model quality matters, but users experience the reliability of the complete workflow.
Enterprise AI becomes useful when it enters existing work without losing identity, context, reliability, or control.
Most "AI product" work is really tool design, approval-flow design, and observability. The model just sits in the middle, doing the easy part. A short essay on what actually makes these systems good.
What you give up, what you get back, where the math actually works out, and the strange small joy of a query plan that ends in s3.GetObject.
A useful word is losing its meaning because it is being used for everything. The repair starts with verbs and authority.
SOC triage starts with the decision surface: what gets grouped, what gets hidden, what needs evidence, and when a human should be asked.
The protocol is small. The interesting design decisions are not: descriptions, schemas, permissions, errors, and when an agent should not use a tool.
Vesting, strike price, dilution, preferences, and exercise terms change what the equity number on an offer actually means.
The gap between a thing that works in the room and a thing that works in a customer's hands on Tuesday morning is where most engineering taste lives.