From AI SOC to AI in the SOC (and beyond) - Keynote session (Ft. Mike Privette)

Most security AI pitches converge on the same modest promise: your analysts will click faster. AI SOC startups have raised hundreds of millions to triage alerts more efficiently, and the incumbents have bolted chatbots onto platforms built a decade ago. In this keynote, Mike Privette of Return on Security pressed Maxime Lamothe-Brassard, LimaCharlie's founder, on why his company stayed quiet through all of it. The answer is a quarrel with the entire frame. Lamothe-Brassard does not think the question is which chatbot triages best. He thinks treating AI as a feature, scoped to one job and locked behind a vendor's roadmap, gets the shape of the technology wrong, and that the cost falls hardest on the service providers running thousands of tenants.

The chatbot was the easy answer to the wrong question

Lamothe-Brassard is candid that the first wave deserved to happen. The early products gave a model a few hardcoded tool calls, wrapped it in a chat box scoped to a handful of use cases, and shipped something useful. He calls it SOAR with some fuzziness, and notes it required almost nothing of the user. The problem is what comes after the first use case. You build the next one, then the next, in the same old product development cycle the industry has run for twenty or thirty years. When every product ships its own chatbot, you are left with the absurd question of whether they are supposed to talk to each other. Privette's deadpan ("you're telling me adding a chatbot to everything does not increase shareholder value?") landed because both men knew the answer was a marketing story, not an operating model.

The deeper objection is timing. The lesson of the past year, Lamothe-Brassard argues, is not how to build the perfect AI tool but that the tools keep getting outpaced. Solutions tuned to a specific model or a specific API get overtaken by the frontier labs within months. He learned this concretely. LimaCharlie has roughly 120 tools exposed through its APIs, and the early attempt to hand them all to an MCP server burned about 70,000 tokens of context before anyone asked a question. A non-starter. MCP is a fine way to connect simple things, but it was never the answer to everything, and plenty of early companies built heavy provider-by-provider infrastructure only to watch MCP arrive and make the work redundant. The point is not that any single approach failed. It is that betting your operation on one is a way to keep losing.

From asking for tools to handing over a goal

What replaces the use-case treadmill is a shift in the unit of instruction, from API thinking to outcome thinking. Instead of wiring one question to one answer, you expose hundreds of real tools, the same APIs and terminal applications a practitioner already uses, and let the model orchestrate its own path to the result. Lamothe-Brassard credits the CLI coding tools, with Claude Code as the early breakout, for making this practical. He reaches for the browser as the analogy: a narrow thing built for one obscure purpose called "the web" that turned out to do almost everything. A year ago you could not hand a model full access to those tools. Now, he argues, you can, and that is the difference between AI as a feature and AI as an operator on par with a web or API user.

The examples carry the argument better than the abstraction does. A level-one analyst points the AI at a new customer and says, in effect, onboard me. The agent discovers the environment, finds the 5,000 Windows machines, the Azure footprint, the Okta logs, reasons about what is worth ingesting from a security standpoint, and presents the operator a plan to approve. Work that might take a senior analyst two days. When something like a fresh "react to shell" vulnerability breaks over the holidays, the operator can ask the AI to research the indicators and techniques, check them retroactively across every tenant, write detection rules, tune them so they do not fire 5,000 times a day, and stage deployment for human approval. None of that is a single flow. It is research, historical analysis, detection engineering, and the operational judgment to know that a constantly firing rule is useless at scale, all stitched together because the agent has access to the whole platform. The third example is the tell: a spend analysis across 5,000 customers, dumped to an Excel file on disk, charted, with outliers flagged. As Lamothe-Brassard puts it, that report exists nowhere on Earth, and it has nothing to do with alert triage. That is exactly why a use-case product can never reach it.

Why the economics, not the cleverness, decide this for a provider

For an MSSP or MDR, the service is the product and AI lands on the margin line, not in a cost-center footnote. This is where Lamothe-Brassard's structural read gets pointed. The AI SOC startups hold genuine expertise but own no EDR, SIEM, or telemetry, so they end up rebuilding the same infrastructure that has always punished service providers around their tenth integration. They need a moat the frontier labs keep eroding, which pushes them toward black boxes, and they have to monetize the AI itself, per token or per alert. Run that math against 4,000 customers and you stop before you start. The incumbents, the bundlers grown through acquisition with products stitched under one web portal, have the capability but are public companies whose incentive is to make AI a new SKU, and whose platforms were built for humans clicking, so every use case needs a fresh access layer behind it. Turning that ship, he says, is the IBM-versus-AWS problem. There was no technical reason IBM could not have been AWS. The ship was just too big to turn.

LimaCharlie's claim is that it stumbled into the right shape by being API-first from day one, a hyperscaler for security operations that happens to have a web portal. That posture is what lets AI operate across the whole stack rather than a sliver. And the move that reframes the economics is that LimaCharlie does not charge for the AI at all. Providers bring their own license and lean on a frontier-model subscription, a fixed monthly cost per analyst, instead of paying per token. The old equation (average alerts per tenant, times dollars per alert, times tenant count, then crying yourself to sleep) becomes a predictable line item that does not spike when one tenant has a noisy day.

The scaffolding that teaches Claude Code how LimaCharlie actually works is published as open source, in plain English rather than hardcoded logic. That is the part Lamothe-Brassard treats as the real engine of differentiation. A provider who dislikes how the AI hunts retroactively for an indicator does not file a feature request and wait. They fork the repo or drop in a short markdown note describing what to favor, and they have changed their service without a development team. His closing advice to practitioners pulls from the software engineering world that sits at the tip of this spear: treat it as a skill to exercise, not a five-minute trial. Do something simple, then something harder, learn why the second thing failed, and keep going. The capabilities are moving too fast, and the verdict from software engineering too one-sided, to assume that what underwhelmed you six months ago will underwhelm you now.