Why the SOC Can't Run on Vibes

On August 14, 2026, Alibaba released Qwen3.8-27B, a 27-billion-parameter open-weight model small enough to run on a laptop. Seventy-two hours later, the first fine-tune had already stripped its safety guardrails. On August 20, a researcher published an "abliterated" version, claiming, by his own testing, a 0% refusal rate across 842 prompts that safety teams are specifically trained to catch. A day after that, a demo of that stripped model running on a Mac, answering exactly the kind of request it was supposed to refuse, with no jailbreak engineering required, was making its way around the industry.

Near-frontier model capability is showing up on hardware anyone can buy within days of release. Months of a lab's safety work can be stripped out by someone else's side project just as fast. If you already have SOC data, and you already have engineers who can write a prompt, the AI SOC you'd otherwise buy starts to look like a sprint or two, not a purchase decision. That's why "let's just build our own AI SOC" sounds like a weekend project right now. 

The aspect often not considered is that the moment you stand up your own model, write your own routing logic, and point it at your own alert queue, you've accepted a job. Congratulations, you're now a security vendor. Any company that has ever sold you a SOC tool has accepted a long list of obligations on your behalf: supporting it, patching it, improving it, and acting on feature requests, the kind of list you rarely had to think about. Build your own version, and that list transfers to you, in full, starting today.

What follows is the fine print of what you have now accepted: the costs, the ceiling on how independent "truly DIY" really makes you, and the oversight that never gets to be optional. The goal here is not to settle a build-versus-buy debate. It's to contrast what any point on that spectrum actually puts on your plate operationally once AI enters the SOC, including how much of it remains human work, no matter who owns it.

Buy, Build, or Somewhere In Between

Buying a platform or building your own looks like a binary choice. It's actually a spectrum, and most organizations are already standing on a point along it without having picked that point on purpose. The hidden costs don't apply evenly across that spectrum. They change shape depending on where you land, and on how much sustained engineering investment security already gets inside your organization. A handful of teams have that investment. Most don't.

• Buy. A platform investigates, routes, and maintains itself on your behalf. You take on very little of what follows in this piece in exchange for working within the boundaries the platform sets. Which data sources it connects to, which models it has already vetted, and how quickly its roadmap moves relative to yours.

• Build-with. You orchestrate agents, MCP servers, or tools on top of infrastructure someone else still runs, patches, and keeps online. You gain real control over the workflow itself: how alerts are routed, what counts as a good verdict for your team, and what a playbook actually does, step by step. That maintenance burden simply relocates, moving from "who runs the model" to "who wires these pieces together correctly, and keeps them wired correctly as every piece changes underneath you." Layering AI on top doesn't fix a slow rate-determining step underneath it. Federated queries against a legacy SIEM architecture are still slow. A disconnect between identity and endpoint still delays remediation. And an agent that can't pull fresh forensic telemetry off an endpoint in real time is reasoning about stale information, no matter how good the model is.

• Truly DIY. Your own model, your own routing, your own infrastructure, built from the ground up. That last part reaches past the application layer, down to the hardware itself, the operating system running it, and every failure or patch cycle that comes with owning both. All of it is now yours to run and defend. Every decision is yours to make, which also means every consequence of that decision is yours to own, on a timeline nobody else is tracking for you.

From the ground up has a real ceiling, and it moves. The frontier you build against today won't be the frontier you're maintaining against once your stack is stable. Closing that gap every time a new model, a new attack pattern, or a new class of threat shows up is a standing commitment with no finish line, and that's a different kind of undertaking than the one-time build most teams picture when they say "truly DIY." Almost nobody actually gets to stop building. The real question is whether you're willing to keep chasing truly DIY indefinitely, on a timeline that resets every time the frontier does.

The far end always sounds smaller than it actually is. "Why not just put it in Amazon S3 with scheduled queries?" is a fair question, and also the first domino. The moment a scheduled query against a growing log store becomes part of your detection or investigation path, you've taken on retention design, query performance at scale, freshness lag, and a cron job as a piece of your incident response infrastructure. Nobody budgeted for that as a security commitment because it didn't arrive labeled as one.

The Job Description You Just Signed

These costs show up as dollars sometimes, but just as often, they show up as time and as coverage gaps that nobody notices until they matter. They don't all carry the same weight. Most of what follows is friction, real friction, the kind that slows a roadmap and eats afternoons, nights, and weekends. One of them is the one that ends up on a postmortem with your name on it.

The friction you'll live with day to day:

Model Choice and Routing

Picking wrong here doesn't announce itself. You find out weeks or months later, usually during an incident, that the model missed something a different one would have caught. Every model swap, frontier to open-weight to whatever ships next, adds a new maintenance task to every workflow already built on top of the old one, and catching a bad pick early means running your own ongoing benchmarking practice against your own data. 
Done well, this pays off. RouteLLM (ICLR 2025) showed that a router can cut costs by more than half while retaining roughly 95 percent of a flagship model's quality on standard benchmarks by sending easy queries to a cheaper model and reserving the expensive one for queries that actually need it. Routing has become its own layer of infrastructure. Whether you build that layer yourself, buy it, or inherit it through your vendor, someone still has to maintain it as the frontier moves.

Infrastructure

Every hop, from your log store to a model API to wherever the response lands, is a boundary you now have to account for, and every new integration adds another one. Hosting the model yourself means that infrastructure work lands on your team specifically. SentinelLABS, SentinelOne®’s threat research team, mapped 175,000 exposed Ollama hosts across 130 countries this year, many with tool-calling enabled, meaning code execution reachable from the open internet. That's the scale misconfigured self-hosting already operates at, in the wild, today.

Secrets management, API keys, service credentials, and model weights need their own rotation schedule that nobody enforces but you.

The Maintenance Surface Nobody Sizes Up Front

Every third-party feed, ticketing hook, or notification channel you wire up is an API you now watch indefinitely for breaking changes and schema drift. Permissions, guardrails, and injection defense for your own agent are now your responsibility. The routing logic, prompts, and evaluation harness usually live in one or two people's heads, and when they leave, the ability to safely change any of it leaves with them.

What You Trade Away 

Building your own tooling lets you tune it precisely to your own environment. The argument for a multi-tenant platform is that it improves for every customer by learning from one customer's incident, whereas a system built just for you only ever learns from you. Threat intelligence feeds are the usual attempt to buy back that value. Still, they trail disclosure by days or weeks, built from indicators already known and published, rather than from what another customer's environment just surfaced in real time.
Concretely, this means detection engineering is now a role someone on your team holds, whether or not anyone actually has that skill set. The open-source route is real and free, but it caps your detection quality at whatever the open-source community has already published, well short of what a platform learning from thousands of customers' incidents sees.

Detection engineering is one of several disciplines this plan usually assumes a single person covers. Model selection and evaluation are machine learning problems. Keeping a distributed system online under real alert volume is a production engineering problem. Guardrails, injection defense, and permissioning are their own specialty again. Vendors absorb this work the unglamorous way by staffing each of those functions separately and keeping them staffed. The DIY version usually assumes one very good engineer covers all four, indefinitely, on top of their existing job.

The One That Ends Up in a Postmortem

Availability and uptime, with no SLA to point to but your own. Long-term support is a permanent operating commitment starting day one. Zero Data Retention (ZDR) agreements with every model provider you route through, negotiated and tracked by you. Compliance posture, SOC 2, or whatever regime applies to your industry, becomes an obligation you own instead of something a vendor had largely absorbed for you.

The question that actually surfaces six months from now, usually at the worst possible time: when an incident happens, is your system's own trail forensically sound enough to support the investigation? Will it hold up to a regulator's or a cyber insurer's questions after the fact? Those are answers worth having ready long before an incident forces the question. 

The Slow Leak Underneath Both

Engineering time spent building and maintaining any of this pulls from everything else on the roadmap, and that opportunity cost compounds well past the initial build. The on-call rotation for a system that runs around the clock, the runbook that has to stay current as the system changes underneath it, and the ramp-up time every new engineer needs before they can safely touch routing logic someone else wrote months ago all surface the same way. A slower roadmap, quarter after quarter.

Coverage gaps open up on a similar rhythm, in the moments nobody plans for. Migrating between models usually means running two systems in parallel for as long as the migration takes, with the coordination overhead that entails. Patching requires a maintenance window, and a maintenance window means a gap in monitoring while it's open. A working, maintained system absorbs those gaps as part of the job it's already doing. Building your own means absorbing them yourself, on your own timeline, with your own team, every time.

Why This Argument Refuses to Pick a Model

Notice what's missing from all of that: a claim about which model is best, or what any of this costs. That's deliberate. The frontier will keep moving no matter what gets published this month, so any argument built on "our model beats your model" has a shelf life measured in weeks. The real question a SOC leader has to answer is who owns the complexity of managing that choice, forever, on top of everything else already on their plate.

That's also the honest answer to "but I can do it cheaper with self-hosted models." The price of a token was never the line item anyone forgot. It's usually the only line item DIY math accounts for. Everything in the section above is the remainder of the invoice, and none of it appears on a model provider's pricing page.

It's also why running a single frontier model for every step of an investigation is the wrong shape for the job, regardless of its cost. Most investigative steps don't need frontier-level reasoning, and treating every task as if they do is an architectural problem before it's ever a budget one. Specialized, right-sized models cost less and run faster without losing accuracy on the work that never needed a frontier model in the first place.

The Oversight You Still Have to Build

Even the best frontier models, under ideal conditions, still need a structured governance framework to remain trustworthy over the course of a long-running investigation. SentinelLABS put this to the test with a benchmark that ran leading frontier models through an eight-stage reverse-engineering exercise built from a real malware investigation. Only one model completed every stage, and even that run required a human to define the objective, control what evidence it saw, and hold final authority over the conclusion. The researchers' own term for the strongest outcome was "supervised investigative agency," not autonomous intelligence.

That's oversight of what a model does once it's running. A separate, harder question sits underneath it – whether the weights themselves can be trusted before you ever get to that point. That's its own problem worth its own treatment, and one this series will come back to.

It speaks to what frontier models need to be trustworthy in general, and the implication holds regardless of what you build on. Being impressive in a demo and being safe to run unsupervised for months are different bars. DIY means you're the one building the second bar, alone, with nobody checking your work until something goes wrong.

The Trailhead Sign

Plenty of teams have good reasons to build, and plenty of the considerations above apply, in some form, no matter what you choose. This is the sign at the trailhead: know what's on the trail before you're a mile in.

For most teams, the trail marked "truly DIY" dead-ends into build-with before it reaches full independence. That's still a real choice, worth making deliberately, it's just rarely the clean break from vendors it sounds like.

It's the same blind spot organizations keep hitting with AI more broadly. Mistaking today's friction for tomorrow's safety, when the friction is often the only thing keeping a bigger problem out of sight.

A SOC can't run on vibes, and neither can the decision to build one. Every item above is a real, ongoing commitment with a name attached to it inside your organization, whether you wrote that name down when you started or not. AI changes how much of this work exists and who ends up doing it. It's still human work, whether it happens on your payroll or a vendor's.

Buy, build-with, or truly DIY. Three lanes, and most teams land in one of them by accident rather than by decision. Worth asking: where are you today, and was that a deliberate call or a default?

Answer that honestly now, and the job description doesn't surprise you in six months. Answer it by accident, and it will.

Third Party Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.