Agentic SOC Detection Engineering Surface
Per-function deep-dive for the Agentic SOC Reference Architecture. It describes how to build the detection engineering agent surface, the function that produces and maintains the detection content the rest of the SOC runs on, and applies the Agentic SOC CMM’s autonomy ladder to it. Detection engineering sits at the front of the detection-and-analysis stage: its output is the rules, queries, and deception that triage, investigation, and hunting consume. The shift the agent surface embodies is from humans writing rules against vendor libraries toward agents authoring and maintaining detections from live telemetry: detection-as-code and detection-in-pipeline.
On the reference architecture’s per-function table, detection engineering runs primarily on the Data & Knowledge plane (it reads live telemetry and the threat-intel graph, and its detection content is the analysis substrate) and the Policy & Enforcement plane (a new or changed detection crosses a deterministic gate — CI tests, shadow rollout, peer review — before it enters production). Its autonomy is gated by D1 (Telemetry & Data Readiness) and D3 (Evaluation & Ground-Truth): an agent cannot author a sound detection without usable telemetry, and a SOC cannot delegate detection authoring it cannot validate. The companion efficacy gate D6 (Detection & Response Tradecraft) scores whether the content is any good once it ships, without capping how much of the authoring is delegated. This page covers cloud-native telemetry plus the in-house GenAI-application surface as a monitored target, where ATLAS-mapped detections substitute for the file and network signatures AI attacks rarely leave.
Domain knowledge in the tooling, not the model, is what makes an authoring agent useful. The recurring practitioner claim across the detection cluster is that what lets an agent operate over billions of sessions or millions of samples is the detection expertise embedded in the tools and data it calls, not the choice of frontier model. The agent surface is therefore designed around the tools and the telemetry, with the model swappable behind them.
The agent surface
On the supervisor-worker topology, detection engineering is a worker-agent pattern the orchestrator invokes to author, refine, and validate detection content. It is not a single autonomous loop; it is a set of bounded tasks whose output is reviewed and tested before deployment.
What the agent does. Three jobs sit under one function. The first is authoring from telemetry: reading live or sampled telemetry, surfacing an emergent campaign or behavior, and drafting a detection for it. GreyNoise’s Orbie is the production instance — an agent operating over internet-scale honeypot data that surfaces threats and writes detection rules, catching campaigns traditional methods missed. The second is CTI-to-detection: converting a threat-intelligence report into a validated rule, the full detection-engineer workflow Microsoft’s CTI-REALM benchmark measures end-to-end (read a report, explore telemetry, write and refine queries, produce validated Sigma plus KQL). The third is detection of natural-language threats on the in-house AI-application surface, where the payload is a sentence rather than a binary and a rule must match attacker intent across paraphrases (SYARA).
Mechanism mix. Detection authoring runs across the full spectrum. Deterministic rule-generation, such as templated Sigma from a known IOC or a parameterized query from a mapped technique, occupies the lower rungs on its own, no AI involved. AI-authored detections sit above it: an agent reasons over telemetry, hypothesizes a detection, drafts the rule, and proposes it. The two are different mechanisms at the same function, and the distinction matters for the autonomy ladder below: a deterministic generator is exhaustively testable, while an AI-authored detection is a non-deterministic output whose quality is a measured property. The hybrid shape is the common one, where an AI agent drafts and deterministic CI plus a human review gate the result.
Tools and data it calls. The agent reads the security data pipeline (live stream, search-in-place over object storage, the threat-intel graph) on the Data & Knowledge plane, and writes detection content into a version-controlled store — detection-as-code in Git, compiled to each backend through Sigma. For the natural-language surface it calls embedding, classifier, and LLM matchers (SYARA’s cost-ordered constructs). Detection-in-pipeline deploys a validated rule onto the live stream itself, where it tags matched events with rule ID, severity, and ATT&CK technique before they reach a SIEM or lake.
Where the human-authority boundary sits. Detection authoring is a relatively safe place for higher autonomy because its output is reviewable before it acts: a drafted rule is an artifact a human or a CI gate can inspect, test in shadow, and approve before it sees production traffic. The boundary therefore sits at deployment, not authoring. An agent may draft and refine detections freely; the Policy & Enforcement plane’s deterministic gate — CI tests against known-benign and known-malicious ground truth, a shadow-production run, peer review — is what a new detection must clear to go live. This is unlike incident response, where the consequential action is irreversible and the boundary sits at the action itself.
Autonomy progression
The ladder below applies the CMM’s per-function autonomy levels to detection engineering. The load-bearing column is the third: a function may run at autonomy L_k only if its governing domains are mature enough to support it. For detection engineering the governing autonomy gates are D1 and D4 at the L2 step, + D3 and D5 at L3, and + D7 and D8 at L4 (the gating rule). D1 and D3 are the function’s distinctive gates: usable telemetry to author against, and the evaluation to know an authored detection is sound. Operating a rung above what those domains support is the model’s defined failure mode — authoring delegated faster than it can be validated.
| Level | What it looks like for detection engineering | Gating domains |
|---|---|---|
| L0 — Manual | A human reads telemetry and CTI and hand-writes every rule against a vendor library. No automation. | — |
| L1 — Assisted | The agent suggests detections or drafts a rule from a report; a human reviews, edits, and commits every one. Deterministic templated rule-generation also lives here. | D1 for usable telemetry |
| L2 — Semi-Autonomous | The agent authors and refines detections as routine sub-tasks; every rule still needs explicit approval before deployment. CI runs on each proposed rule. | D1 (telemetry to author against) · D4 (the agent’s authoring identity and scoped write-access are controlled) |
| L3 — Conditional | The agent authors, tests, and deploys detections within bounds — for example, content for a mapped technique that clears CI and shadow-validation — escalating novel or high-impact rules; humans monitor the standing detection set. | + D3 (evaluation to measure whether authored detections are sound) · D5 (the authoring pipeline is observable and reversible) |
| L4 — Delegated | The agent owns the detection lifecycle for its scope — authoring, validating, deploying, retiring stale content, and tuning against drift — under outcome governance. Asymptotic: a human still governs the policy that bounds it. | + D7 (the authoring agent is resilient and supply-chain-secure) · D8 (governance of the autonomy-raising decision) |
Two function-specific points sharpen the gating rule here. First, the reviewable-output property makes L2 and L3 reachable earlier than for action-taking functions: because a drafted detection is validated by D3 before it acts, the SOC can delegate authoring at L3 once it can measure detection quality, where reckless containment at the same rung would demand the heavier D4 and D8 maturity that gates an irreversible action. Second, detection-in-pipeline at scale is gated harder by D1 than detection-as-code is. Deploying a rule onto the live stream means the authoring agent must reason over telemetry that is broad, current, and correctly normalized; a partial or stale pipeline produces detections with silent blind spots. A SOC can run detection-as-code authoring at L3 on a modest pipeline, but detection-in-pipeline at scale needs the D1 coverage and freshness instrumentation that only matures at higher D1 levels.
The failure mode is concrete. A detection function delegated to L3 or L4 while D3 is immature is authoring and deploying detections nobody can confirm are sound — the SOC is generating coverage it cannot trust, and a noisy or blind rule reaches production without the validation that would have caught it. The prescriptive output is to mature D3 (a rubric, a regression suite, a curated ground-truth store) before raising authoring autonomy, not to raise the autonomy and hope.
Control landscape (dated)
Detection engineering has a mature content, format, and testing core; the new layers are AI-authored content, semantic detection of natural-language threats, and cross-organization sharing of attack intelligence. The AI-specific particulars are dated and swappable, marked GA versus preview.
| Capability | What ships today | Status (mid-2026) |
|---|---|---|
| Portable detection format | SigmaHQ as the vendor-agnostic rule format, compiled to each backend’s query language; community content layered on top | GA; the de facto open detection-content interchange |
| Detection-as-code | Detection content in version control with CI tests against known-benign and known-malicious ground truth, peer review, and shadow rollout before production | GA as a practice; uneven in adoption, and the discipline, not a single product |
| Detection-in-pipeline | Sigma rules applied to the live stream before data lands — SOC Prime DetectFlow over Kafka through an Apache Flink pipeline, tagging matched events with rule ID, severity, and ATT&CK technique (see the pipeline architecture) | GA in the named product; an emerging category, and the scale/latency figures are vendor-reported |
| AI-authored detection | Agents that surface emergent campaigns and write rules from live telemetry — GreyNoise Orbie over internet-scale honeypot data | Production at a vendor; a leading-edge pattern, not a packaged product for most SOCs |
| CTI-to-detection benchmark | CTI-REALM (Microsoft), measuring end-to-end CTI→validated Sigma/KQL generation with checkpoint scoring on ATT&CK mapping and query refinement | Open-source research benchmark (published March 2026); per-model leaderboard partly unpublished |
| Semantic / intent detection | Rules that match attacker intent across paraphrases for natural-language threats, cheap pre-filter gating an expensive LLM verdict — SYARA, open-source | OSS and installable (pip install syara); benchmark figures are the project’s own, not independently reproduced |
| Cross-org detection sharing | Privacy-preserving fingerprints that let siloed LLM services share prompt-injection intelligence across compliance boundaries — BinaryShield (Microsoft) | Research-stage; backed by a published paper, no packaged product |
| Detection / control validation | Atomic Red Team for technique-level tests; breach-and-attack-simulation (BAS) platforms; purple-teaming to confirm a detection fires on a real technique | Atomic Red Team is OSS and free; BAS is commercial; both GA |
| Deception detections | Canaries and honeytokens keyed to TTPs, including deception against AI-powered attackers, feeding detections (Orbie’s deception half) | Canary/honeytoken tooling is GA; AI-attacker-keyed deception is emerging practice |
| AI-application threat surface | MITRE ATLAS as the threat model the in-house GenAI-application detections map against — prompt injection, jailbreaks, RAG exfiltration, agent hijack | GA reference; the monitored AI app is a distinct asset class because its attacks rarely leave traditional signatures |
The load-bearing shift is from byte-signature matching against vendor libraries to intent matching authored from live telemetry. Orbie shows authoring: an agent drafting rules from honeypot data, where the tooling’s domain knowledge beats model choice. SYARA shows intent matching for natural-language threats with a cheap layer gating the expensive LLM to keep cost survivable at scale, and BinaryShield extends detection from one service to a privacy-preserving sharing layer. Validation — Atomic Red Team, BAS, purple-teaming — is what turns authored coverage into confirmed coverage, and is the D3/D6 mechanism behind safely raising authoring autonomy.
Failure modes and what to watch
- Authoring above the earned ceiling. Detection authoring delegated to L3/L4 while D3 is immature produces detections nobody can confirm are sound. Bounded by the gating rule: raise authoring autonomy only as fast as evaluation maturity permits, and gate every rule through CI and shadow rollout on the Policy & Enforcement plane.
- False-positive collapse. An authoring agent optimizing for coverage floods the queue with noisy rules, eroding trust in the whole detection set and feeding downstream alert flooding at triage. Bounded by false-positive rate as a tracked, governed metric (D6) and a shadow-production run before any rule is enabled, the rollout discipline SYARA prescribes (run a new rule in shadow for about a week before production).
- Blind-spot detections from a thin pipeline. Detection-in-pipeline authored over partial or stale telemetry deploys rules with silent gaps that look like coverage. Bounded by D1 coverage and freshness instrumentation; the harder the pipeline scale, the higher the D1 floor.
- Unvalidated coverage. A detection mapped to an ATT&CK technique is not the same as a detection that fires on it; a coverage map without BAS or purple-team validation overstates real coverage. Bounded by D6’s validation discipline — confirm the rule fires on the real technique before counting it.
- Cost runaway on intent detection. An LLM-graded detection run on every input is unaffordable at production volume. Bounded by the pre-filter pattern — a cheap string or classifier layer gating the expensive LLM, ordered cheapest-first.
- The blind AI-application surface. AI attacks on in-house GenAI apps rarely leave file or network signatures, so traditional detection authoring never covers them. Bounded by ATLAS-mapped detections and AI-application telemetry as a D1 readiness requirement; the detection has to read prompt and agent traces, not host effects.
Validating authored detections at authoring speed is the open gate
The gating rule makes D3 evaluation the rung that legitimizes delegated authoring, yet the wiki has no method that confirms an AI-authored detection is sound at the rate an agent can produce one. The trustworthy check that a rule fires on a real technique — BAS, purple-teaming, a curated ground-truth run — is slow and largely manual, while authoring is the part AI accelerates. Until validation throughput catches up to authoring throughput, L3/L4 authoring outruns the only control that bounds it and a coverage map grows faster than confirmed coverage. Where the validation-to-authoring ratio has to sit before delegation is safe is unmeasured.
Right-sizing by org profile
The realistic authoring autonomy for detection engineering is scored against the organization’s scale, its pipeline maturity, and whether it runs an in-house AI-application surface. A small team consuming a provider’s curated detection content is right-sized, not immature.
| Band | Realistic autonomy target | Why |
|---|---|---|
| Solo / small | L1 → L2 | Near or below the cyber poverty line, a small team cannot author and validate broad coverage alone. The path is borrowing: an MSSP/MDR or managed stack supplies curated, ATT&CK-mapped content, and the team consumes SigmaHQ community content rather than authoring its own. AI lowers the floor here — an assistant that drafts a rule from a report or tunes a Sigma template makes detection-engineering reachable for a team that could never staff a detection engineer — but with a human approving each rule, because the D3 to delegate authoring is not yet built. |
| Mid | L2 → L3 | An in-house detection-engineering function can run detection-as-code with CI tests and stand up the D3 rubric and regression suite to delegate authoring within bounds on a mapped technique. Detection-in-pipeline and extending coverage to an in-house AI-application surface (ATLAS) are the stretch goals, gated by the D1 pipeline maturity each needs. |
| Enterprise | L3 → selective L4 | A dedicated detection-engineering team and the telemetry volume to justify AI-authored content and intent-detection at scale. L4 lifecycle ownership earns its cost on the functions where authoring volume outpaces manual review and the D3/D5/D7/D8 maturity to govern it is in place; deception keyed to AI-attacker TTPs and detection-in-pipeline at scale belong here. |
The small-team column is where AI most plainly lowers the barrier. Detection engineering historically demanded a skill (writing and tuning detection content) and a pipeline most small teams could not afford; an authoring assistant plus borrowed, curated content puts the lower rungs within reach of teams below the traditional cyber-poverty line, provided each rule still crosses a human-review gate.
Relations
- Per-function deep-dive of the Agentic SOC Reference Architecture; detection engineering runs on its Data & Knowledge plane (telemetry, threat-intel graph, detection content) and Policy & Enforcement plane (the deterministic deploy gate).
- Applies the Agentic SOC CMM’s autonomy ladder to detection engineering, gated by D1 Telemetry & Data Readiness and D3 Evaluation & Ground-Truth; detection-content quality is scored by the efficacy gate D6 Detection & Response Tradecraft, which does not cap authoring autonomy.
- The Data & Knowledge plane this function reads is detailed in Security Data Pipeline Architecture (detection-in-pipeline, search-in-place).
- Practitioner evidence: GreyNoise Orbie (AI-authored detection and deception from internet-scale honeypot data), SYARA (cost-ordered semantic detection of natural-language threats), BinaryShield (privacy-preserving cross-org threat-intel sharing), and CTI-REALM (the CTI→validated-Sigma/KQL benchmark). The in-house AI-application surface is modeled by MITRE ATLAS.