Security-operations agents: the only agent whose input is written by an adversary who knows you are reading it.
Every other agent in this section handles input that is careless, ambiguous or occasionally malicious. A SOC agent handles input that is authored — log lines, filenames, HTTP headers, phishing bodies, process arguments — by someone whose job is to change what you conclude, who now knows a model reads it first, and who can iterate until they find a phrasing that works. That single property reorders the whole design: the enrichment must be deterministic, the model must never be the thing that decides an alert is benign, and the metric that matters is not alerts closed but the rate at which the agent talks an analyst out of a real incident.
Name the job, because "reduce alert volume" is the wrong one.
The pitch for a SOC agent is always triage volume: tens of thousands of alerts, a handful of analysts, an obvious arithmetic case for automation. That framing produces a product optimised to close alerts, and closing alerts is trivially easy to do well on every metric except the one that matters.
The honest objective is analyst seconds to a defensible decision, subject to a false-close rate that does not move. Both halves are load-bearing:
- Seconds to decision, not alerts handled. Most of an analyst's time on a routine alert is not judgement — it is fifteen minutes of pivoting between six consoles to answer questions with deterministic answers. Is this IP in our ranges? Has this hash been seen before? Is this user on leave? Did anything else fire on this host in the last hour? Collapsing that to a paragraph the analyst reads in twenty seconds is a real, large, and safe win.
- The false-close rate is a constraint, not a metric to trade. A missed intrusion does not cost you an alert; it costs you the entire dwell time until something else catches it. The asymmetry is more extreme than in almost any other domain in this section — which, per the five-question method, is what should dictate autonomy.
There is a second job people miss, and it is often the better one to ship first: the agent as a writer, not a decider. Producing the timeline, the case notes, the customer-facing summary and the post-incident draft is real work, consumes senior analyst hours, has an obvious ground truth, and carries essentially no downside if it is wrong — a human is reading and editing it anyway. Teams that start here get value in weeks and build the trace corpus they will need to evaluate triage later.
The adversary writes into your context.
This is the property that makes the domain different, and it is not hypothetical. If a model summarises alerts, then any field an attacker controls is an input to that model: a filename, a user-agent string, a commit message, the body of a reported phishing email, a DNS query, the command line of a process they launched. An attacker who suspects an LLM is in the loop — which by now is a reasonable default assumption — can put text in those fields aimed squarely at it.
- Everything from the wire is data, never instruction. Alert content, log excerpts and threat-intel comments arrive in a clearly delimited block that the system prompt describes as untrusted attacker-supplied text. This is the same discipline as prompt injection 101, applied where the threat model is not speculative.
- The model cannot hold the verdict. Design so that no sequence of attacker-authored text can cause an alert to be closed. The model may rank, summarise, and recommend; the close is either an analyst's click or a deterministic rule that reads structured fields the attacker does not control. If a persuasive paragraph in a log line can suppress an alert, you have built the adversary a suppression API.
- Truncate and neutralise at the tool boundary. Cap the bytes of raw content that reach the context, strip or escape control sequences, and never let retrieved content carry links the model might follow. A 50KB attacker-authored blob in the context is both a cost problem and an attack surface.
- Watch the exfiltration direction too. A SOC agent has read access to the most sensitive telemetry you own. An injection that makes it emit that content into an outbound tool call — a ticket comment, a webhook, a URL fetch — is the highest-value outcome available to an attacker in your environment. Egress from the agent belongs on an allowlist. See data exfiltration risks.
The defenses that work here are structural, not prompt-level; prompt-injection defense covers the mechanics. The domain-specific point is that this is the one deployment where you should assume a motivated adversary is actively probing the agent, and where "we told the model to ignore instructions in the data" is not a control.
Enrichment is deterministic; the model does ranking and prose.
The reliable architecture separates two things that demos usually merge. Retrieval of facts is code. Interpretation of facts is the model. Blur them and you get a system that hallucinates asset ownership.
- Enrichment tools return structured facts, not paragraphs. Asset owner, business criticality, patch level, user's department and leave status, historical alert count for this rule on this host, reputation lookups, whether the hash has been seen in the estate before. Each is a typed field with a source and a timestamp. See tool design for agents.
- Correlation is a query, not a judgement. "What else fired on this host in the last hour" is a deterministic search. Let the model interpret the result set; do not let it decide what the result set is.
- The model's output is a recommendation with citations. Every claim in the summary points at the enrichment field or log line it came from. An analyst must be able to check any sentence in one click — this is what makes a twenty-second read possible, and it is also the only defence against a fluent summary of facts that were never retrieved.
- Confidence must be about evidence, not tone. "No prior detections for this hash; asset is a developer laptop; user confirmed the download in Slack" is useful. "Low confidence this is malicious" is a number the analyst cannot audit and will learn to ignore.
A concrete anti-pattern worth naming: retrieval-augmented threat intelligence where the agent searches the open web and summarises what it finds. Threat-intel blogs are attacker-observable and attacker-writable; content farms and poisoned indicators are a known problem. Restrict the agent to feeds you have a reason to trust, and treat anything from open search as a lead for a human, never as an input to a verdict — the same argument as RAG security, with a more capable adversary.
Autonomy by reversibility, and containment is not reversible.
Sort actions by what it costs to be wrong, which in this domain means asking who is harmed by a false positive as well as by a false negative. Automated containment is where SOC automation has historically caused its own outages, and an agent does not change that arithmetic.
- Autonomous — read, enrich, correlate, cluster duplicate alerts, draft the case note, rank the queue, open a ticket. All reversible, all high volume, all where the agent earns its keep.
- Gated on a human — isolating a host, disabling an account, blocking a domain, revoking a session, quarantining mail. Each of these is an availability action against a real person or a production system, and each has a well-known failure story where an automated rule took out something important at 3am. The DevOps and SRE playbook makes the same argument about production changes; here the additional wrinkle is that triggering containment is a plausible attacker goal, not just an accident.
- Never — anything that mutates the evidence: deleting alerts, editing logs, closing a case as a duplicate without a record, tuning a detection rule. Detection tuning in particular looks like housekeeping and is the single most dangerous write an agent could have, because a suppressed rule is invisible by construction.
- Scope the credentials to match. The agent's read access should be broad and its write access almost nonexistent, enforced by the token rather than by the prompt. See scoped credentials.
There is a narrow case for automated containment: a high-fidelity detection, a well-understood asset class, a documented rollback, and a rate limit that stops a bad hour from becoming an outage. That case exists, it is rare, and it should be a deterministic playbook the agent invokes — not a decision the model composes.
Evaluate against the errors you will never be told about.
SOC triage has a nasty measurement property: you find out quickly when the agent escalates something benign, and you may never find out when it de-prioritised something real. Optimising on the feedback you receive therefore drives the system in exactly the wrong direction, and it will look like it is improving the whole time.
- Build the golden set from closed incidents, both outcomes. Historical alerts where the true verdict is known — including the true positives that were originally missed and found later — are the only data that scores the failure you care about. That set is small and expensive; it is also the only honest instrument you have.
- Score the trajectory, not just the verdict. An agent that reached the right conclusion without pulling the evidence got lucky and will not stay lucky. Assert on the tool calls: did it check the asset criticality, did it query for related alerts. See outcome vs trajectory evaluation.
- Put injection cases in the suite as a permanent category. Alerts containing text engineered to produce a benign verdict, in the actual fields your pipeline ingests. Every new tool integration adds a new field an attacker can write to, so this category grows with the system.
- Run a sampled human re-review of auto-handled alerts — a small percentage, indefinitely, staffed as a standing cost. This is the only mechanism that detects drift in the direction you are blind to, and it is invariably the first thing cut when the agent appears to be working.
- Track analyst override rate in both directions. Overrides falling toward zero is not maturity; it is usually automation bias arriving, and it means your reviewers have stopped being reviewers. See human in the loop.
The lines that do not move.
Security operations sits inside obligations that predate the agent and are unmoved by it. Breach-notification clocks start when the organisation knew or should have known — an agent that saw and de-prioritised an alert is an argument that the clock started earlier, not later, so the record of what the agent concluded and why is a legal artifact, not a debugging convenience. Keep it in an audit trail the agent cannot write to. Chain of custody for evidence is unchanged by the collector being a model. And a SOC agent must not be the sole detection path for anything: it is a layer over your detections, never a replacement for one, because a model outage or a quiet regression would otherwise be indistinguishable from a quiet week.
One more, easy to overlook: the agent's own traces are now some of the most sensitive data in the estate — enriched telemetry, asset criticality, user context, and a map of what your detections actually look for. Treat that store with the same controls as the SIEM it reads from, and remember that a compromise of the agent's own incident path is a security incident about your security tooling.
Ship enrichment and case-writing first, keep the verdict with the analyst, and put the injection test suite in CI on day one rather than after the first incident. The enrichment layer delivers most of the available time savings, carries almost none of the risk, and produces the labelled traces you will need before you can honestly evaluate anything more autonomous. The agent should make a human faster at deciding, not decide; in the one domain where the input is written by someone trying to fool the reader, the model must never be the last thing between an alert and its dismissal.
Related: the agentic threat model for the systematic version of step 2, DevOps and SRE agents for the sibling domain with the same blast-radius discipline, and adapting a playbook for the method behind this one.