Where agents earn their place

Ask an analyst where the time goes and the answer is rarely the decision. It is the twenty minutes before the decision: pulling asset context, checking recent changes, finding the owner, looking for related findings, and writing it all into a ticket. That work is structured, repetitive, and verifiable, which makes it the right place to start.

Alert triage

A triage agent receives the alert, gathers the context an analyst would gather, and produces a ranked recommendation with the evidence attached. What is the asset, who owns it, is it exposed, what changed recently, has this pattern been seen before. It drafts the ticket. Where policy allows, it closes the classes that are known-benign and well understood. Everything else goes to a person who now opens a ticket that is already half done.

Vulnerability correlation

Scanner output is a list. Risk is a graph. A correlation agent joins findings with the asset inventory, ownership, internet exposure, exploit availability, and compensating controls, then produces a remediation queue ordered by real risk instead of by score. It opens tickets with the fix and the owner attached and checks later whether the fix landed. Hopbyte's founder runs vulnerability management across a multi-account AWS Organization, and this is the part of the job that most benefits from automation.

IAM drift detection

Identity drifts. A role picks up a wildcard during an incident and keeps it. A cross-account trust is added for a migration and never removed. A drift agent compares live roles, policies, and trust relationships with the intended baseline, flags new admin paths and broad grants, explains why each one matters, and proposes a least-privilege replacement. The proposal goes to a person. The agent does not edit IAM.

Where agents must not act alone

Some actions are never autonomous, no matter how good the precision numbers look:

  • Destructive actions: deleting resources, wiping hosts, purging data.
  • Access changes: revoking production access, rotating credentials that other systems depend on, editing IAM.
  • Broad containment: blocking traffic at a scope that could take down a service.
  • Outbound communication: anything sent to customers, partners, or regulators.
  • Any action derived from untrusted content, where the alert or the email is the thing telling the agent what to do.

The cost of a false positive in these classes is an outage, a locked-out on-call engineer, or a disclosure that cannot be taken back. The agent prepares the plan and the evidence. A person approves it. The agent executes through scoped tools and documents the result. That sequence is slower by a minute and safer by an order of magnitude.

Prompt injection is a security operations problem

Alert payloads, email bodies, log lines, and user-agent strings are text. Some of that text was written by the attacker. If an agent reads it as instructions, the attacker has a new capability: tell the SOC's own tooling what to do.

The defense is structural, not clever prompting. The agent treats all observed content as data. Its tools have allowlists and typed inputs, so a string in a log line cannot become a new command. The agent's identity is separate from any analyst and scoped to its tools, mostly read-only. Every tool call is logged to the SIEM, which means an injection attempt that gets as far as a tool call is itself an alert. Design it that way from the start and prompt injection becomes a finding rather than a breach.

Designing the human in the loop

Human-in-the-loop is a design, not a checkbox. Done badly, it is a stream of approval requests that people click through without reading. Done well, it is a small number of decisions with everything the decider needs in one place.

Action classes. Group every action the agent can take by reversibility and blast radius. Each class gets a rule: autonomous, autonomous with notification, or approval required. The rules are written down and reviewed.

Shadow mode. Before any action is enabled, the agent runs alongside analysts and its recommendations are compared with their decisions. Precision is measured per alert class. A class is promoted only when the number holds over enough volume to mean something.

Evidence packs. The approval request shows the plan, the evidence that led to it, and what the action affects, in the ticketing or chat tool the analyst already uses. No context switch, no hunting.

Override tracking. Every time a person reverses the agent, the case is recorded and added to the evaluation set. A class with rising overrides gets demoted. This is the feedback loop that keeps the agent honest over time.

Fatigue budget. If the agent generates more approval requests than the team can read with attention, the gate has failed. Either the precision improves or the class goes back to recommend-only.

A reference architecture in plain words

Alerts and findings flow into a queue. The agent reads from the queue with read-only tools, enriches, correlates, and produces a recommendation with evidence. Recommendations for autonomous classes execute through scoped write tools and notify. Recommendations for gated classes become approval requests in the analyst's tools. Every step, tool call, and approval is written to the SIEM. A kill switch pauses the agent in one action. Cost ceilings stop runaway runs. The model can be a frontier API through your cloud provider, or a fine-tuned open-weight model hosted in your VPC when alert data must not leave your boundary.

Start here

Pick the alert class that costs the most analyst time and has the clearest right answer. Build the triage agent for that class only, read-only. Run it in shadow mode until the precision is boring. Then enable ticket drafting, then auto-close for the benign subset, then the next class. Each step is small, measured, and reversible, which is how security work should be automated.