I split my week between two communities that, by my count, almost never talk to each other.
Monday and Tuesday I'm an AI red teamer — running adversarial test campaigns against frontier LLMs, writing rubrics that try to catch reward hacking, auditing agentic trajectories for the kinds of failures a benchmark wouldn't surface. The vocabulary is alignment, evaluation, prompt injection, jailbreak taxonomy, "did the model do the thing it said it did, or did it sandbag the test?"
Wednesday and Thursday I'm a SOC analyst — triaging Splunk notables, tuning Microsoft Defender alerts, automating MISP threat intel, writing detection rules that survive contact with reality. The vocabulary is MTTD, false-positive ratio, alert fatigue, runbooks, "what does the analyst do at 3am when this fires?"
These two worlds share a foundational truth: in both, the defender is outnumbered, and the attacker only has to be right once. Both are about asymmetric games where you fail in production and learn in public.
And yet the communities barely overlap. AI safety conferences cite Bruce Schneier and the SANS Top 25 maybe once a year. SOC training programs barely mention prompt injection. The OWASP Top 10 for LLM Applications is the closest thing to a bridge document we have, and most people I know in either field haven't read it.
This is a problem — for both sides. Here's why.
What SOC people bring to AI security
Most AI safety work today, when it touches "security" at all, looks like this: someone runs a batch of adversarial prompts against a model, observes failures, and writes them up. That's offensive security. It is one part of a security program. It is not most of one.
What's missing — what SOC people would notice immediately — is detection, monitoring, response, and the operational discipline to keep a security control alive past its first deployment.
Three concrete things SOC discipline would import into AI security:
Detection engineering.
When I write a Splunk detection, I don't just write the SPL. I write a hypothesis ("this combination of behaviors should never occur in benign traffic"), a tested example ("here's a synthetic event that triggers it"), a documented false-positive profile ("here are the legitimate use cases that look similar"), and a runbook ("when this fires, here's the first five things the analyst checks").
Compare that to most "AI safety evaluations" I've seen, where a finding looks like: we tried these 50 prompts, the model failed on these 12. That's the what. What's the runbook? When the model fails this evaluation in production, what does an on-call engineer do? Most teams don't have an answer.
Tuning over time.
A SOC detection that fires once and never gets revisited becomes noise. Same is true of an AI safety evaluation. If a model passes your prompt injection test today, that pass is meaningful for today's model, today's deployment, today's threat patterns. Without continuous re-evaluation against new attack patterns, the test becomes ceremonial.
SOC teams have decades of experience with detection lifecycle management — write, test, deploy, tune, retire. AI safety teams are mostly still on "write" and "deploy."
Triage discipline.
When 200 alerts hit a SOC at the same time, the first task is sorting which ones might actually matter — not investigating all 200. AI safety evaluations produce hundreds of "findings" per run. Which ones are red-team-finding-worthy and which ones are noise? SOC analysts have explicit frameworks for this (severity, exploitability, impact, asset criticality). AI safety teams are reinventing those frameworks from scratch, often badly.
What AI red teamers bring to SOC
The flow goes the other way too. Most SOC teams I've worked with have a blind spot the size of an LLM-shaped hole.
Three things AI red team mindset imports into SOC:
Adversarial creativity beyond the playbook.
Traditional SOC work is heavily playbook-driven. That's fine — playbooks are how you scale a team and onboard new analysts. But playbooks codify yesterday's attacks. AI red teamers are trained to ask "how could this go wrong in a way that has never happened before?" That muscle, applied to a SOC environment, surfaces detection gaps that the existing detection set will never catch.
For example: most SOCs I've seen do not have detections for "an internal user is using an LLM-integrated assistant to extract data they shouldn't have access to." That's not in any 2022 playbook.
Surface enumeration discipline.
When I do a prompt injection assessment of an LLM application, the first phase is mapping every untrusted input the model can ingest — user input, retrieved documents, tool outputs, image alt text, OCR'd content, function-call return values. Each is a separate trust boundary. Each is a separate attack surface.
Most SOC programs don't think about their environment this way. They monitor "endpoints" and "network." But every internal SaaS tool that ingests user-controlled content is an attack surface. Every webhook is an attack surface. Every CSV import in a finance tool is an attack surface. AI red teamers think this way by default. Traditional SOC programs often don't.
The "agent" lens.
This is going to be the big one over the next five years. As agents proliferate inside enterprises, the attack surface multiplies non-linearly. An agent that can write code, send emails, query a database, and trigger workflows is a single human-in-the-loop deflection away from being a threat actor with full kill-chain capability.
AI red teamers think about agents this way. SOC programs are not yet structured to detect compromised agent behavior. They will need to be.
Three quick stories
Lightly anonymized, but real.
One. A security team I worked with had a sophisticated SIEM, well-tuned alerts, a mature SOC. They had no detection for an LLM-integrated app pulling sensitive data into a prompt window in response to an attacker's input. The data was logged. The query was logged. But there was no detection rule that said "this internal LLM app received a query with these patterns and then responded with content from a sensitive data source." The SOC was operating with 2018 rules in 2026. AI red team mindset would have surfaced the gap in an afternoon.
Two. An AI safety evaluation I contributed to catalogued 47 jailbreak patterns surviving the latest model. Beautiful work. Zero of those findings had a corresponding detection rule, runbook, or operational response plan. If those 47 patterns hit the model in production, what happens? Nobody had asked. SOC mindset would have closed the loop in a sprint.
Three. I watched a team treat "prompt injection" as one threat — a checkbox on a risk register. AI red teamers know prompt injection is a category with at least nine distinct mechanisms, each requiring a different defensive control. Treating the category as a single thing produces single-thing controls. Single-thing controls don't survive contact with attackers.
What "the bridge" looks like in practice
I'm building toward what I think the next five years of security careers will look like — and what I think most security leaders should be hiring for. The shape of it:
SOC programs that have an AI red teamer on staff. Not as a curiosity hire. As a senior contributor whose job is to surface attack surfaces the existing detection set will never catch. Embedded with the detection engineering team, not isolated in a research role.
AI safety teams that have a SOC veteran on staff. Not as a curiosity hire. As a senior contributor whose job is to harden the operational edges around evaluations, build detection-engineering rigor into the safety-eval lifecycle, and answer "what's the runbook?" for every finding.
Joint exercises. A purple-team-style engagement where a SOC team and an AI red team run together against a single environment that includes both traditional infrastructure and LLM-integrated applications. I've never seen this run as standard practice. It should be standard practice.
Shared vocabulary. OWASP Top 10 for LLM Applications, OWASP Top 10 for Agentic Applications (2026), MITRE ATLAS, NIST AI RMF — these are the bridge documents. SOC programs that don't read them are flying blind in 2026 environments. AI safety programs that don't read SANS, NIST CSF, or ISO 27001 are reinventing detection lifecycle management with worse tooling.
Closing
If you're a SOC analyst reading this and you've been waiting for a sign that AI security isn't "someone else's problem" — this is it. Your discipline transfers. The detection engineering muscle you've spent years building is exactly what AI safety needs. Start with the OWASP LLM Top 10 this weekend. You'll be ahead of most "AI security" people inside a month.
If you're an AI safety researcher reading this and you've been doing offensive work without a coherent operational follow-through — your evaluations need a SOC layer. Build it. Or hire someone who already has.
If you're a hiring manager — the candidates who can do both are rare today. They will be the senior security architects of 2030. Hire them now while they're still affordable.