What an Agentic SOC Actually Automates, and the Three Things It Assumes You Already Run

Should a two-person security team buy an AI SOC analyst? The vendors demoing sixty-second alert triage would like the answer to be an easy yes, and the pitch lands because the problem underneath it is real. In the fastest quarter of intrusions Palo Alto's Unit 42 investigated last year, attackers moved from initial access to data exfiltration in 72 minutes, down from 285 the year before. A human on-call rotation cannot keep pace with that. An agent that reads an alert, enriches it, and returns a verdict in about a minute is answering a question every defender is asking.

The question underneath the pitch is the one this piece is about: what does an agentic SOC actually do once you switch it on, and what does it quietly assume is already in place? Having spent time inside both a large enterprise SOC and small-business environments, I can tell you the demo and the deployment are two different animals. The agents are genuinely useful. They are also only as good as the plumbing you hand them, and most of the teams being sold on autonomy have not built that plumbing yet.

What today's SOC agents actually do

Strip away the "autonomous SOC" branding and the current generation of agents aims at one stage of the workflow: alert triage and initial investigation. That is the right target. Triage is where analysts drown, and it is repetitive enough that a model can carry real load.

The two biggest platforms have shipped concrete versions of this. Google's agentic SOC pairs a Gemini-native triage and investigation agent that, in Google's own numbers, compresses a roughly thirty-minute manual alert analysis to about sixty seconds by pulling threat intelligence, building context, and returning a verdict with its reasoning. Microsoft's Security Copilot in Defender runs an Alert Triage Agent that autonomously classifies, prioritizes, and resolves the low-value, repetitive alerts that eat a shift; Microsoft reports its agentic phishing triage surfaces 6.5 times more malicious alerts than analysts working the same queue alone, and it expanded the lineup again at RSA 2026.

Read those claims precisely. The agent is not finding threats nobody logged. It is reasoning faster and more consistently over signals that were already flowing into the platform, and it clears the noise so a human looks at the twenty alerts that matter instead of two thousand. That is a real gain in tempo and consistency. It is also the exact place where the assumptions hide.

Who this is for, and who can put it down for now

If you run a SIEM or an EDR that already collects decent telemetry, and you have a queue no human can keep clean, an agentic triage layer is worth a serious pilot this quarter. That describes a lot of MSPs and internal teams sitting on a Microsoft Defender or cloud-native stack they are barely reading. This story is yours.

If you have no central logging, no EDR, and no SIEM, which describes a large share of the small businesses I assess, then an AI SOC analyst is premature, and the vendor selling you one is selling you the second thing you need before the first. An agent that triages alerts has nothing to do when nothing is generating alerts. Your first dollar goes to telemetry and coverage. Being honest about that is the whole point: the tool is good, and it is not yet yours.

Everyone in between, some logging, a half-tuned SIEM, one overloaded person, is where the decision gets interesting, because the agent will work, but only as well as the three things below are true.

The three things an agentic SOC assumes you already run

An agent that triages alerts is a reasoning layer bolted on top of an operational stack. It inherits every gap in that stack, and it cannot tell you about the gaps it inherited. Three prerequisites decide whether you get sixty-second triage or sixty-second confident nonsense.

1. Telemetry worth reasoning over

The agent triages what you collect. If your Windows endpoints are not forwarding process-creation and PowerShell logs, if your identity provider's sign-in logs are not ingested, if your firewall egress is never captured, then the agent renders confident verdicts on a partial picture and stays silent on the half of the attack it never saw. A blind spot in your logging becomes a blind spot in the agent's judgment, except now it carries the authority of a machine that "investigated" and closed the alert. Coverage first, autonomy second.

2. A response path it is allowed to take

Triage that ends in a verdict nobody actions is a faster way to generate ignored tickets. The value shows up when the agent can drive a response, isolate a host, disable an account, revoke a session, inside guardrails you set. That means those response actions have to be wired up, and, more importantly, you need an explicit allow-list of what the agent may do on its own versus what it must escalate. Handing an autonomous system the power to quarantine machines without a scoped policy is how a false positive becomes your own outage.

3. Someone who owns the verdicts

The agent is fast and consistent, and it is wrong often enough that the residual work is judgment, not volume. Someone has to tune it, sample its closes, and catch the confidently-wrong five percent before it becomes an incident. The industry has been describing this shift for a year: ISC2's 2025 workforce study found 95 percent of teams reporting at least one skills gap and 59 percent citing critical or significant shortfalls, up from 44 percent a year earlier. Agents do not erase that gap. They move the scarce skill from "read every alert" to "supervise the thing that reads every alert," which is a smaller job but a harder one.

What the guardrails look like in practice

The difference between a deterministic automation and an agentic one is what the system is permitted to do after the detection fires. A traditional SOAR playbook runs a fixed branch. An agent chooses the branch, which is exactly why the allow-list matters. The piece you own is a policy that scopes the agent's authority, not the model itself:

# Agent action policy - the guardrail you own, not the model
detection: identity.impossible_travel
triage_agent:
  autonomous_actions:        # agent may take these without a human
    - enrich: [geoip, threat_intel, recent_signins]
    - revoke_session
    - require_reauth
  escalate_only:             # agent must hand these to a human
    - disable_account
    - isolate_endpoint
  never:                     # off-limits regardless of confidence
    - delete_mailbox
    - modify_conditional_access_policy
  guardrails:
    max_autonomous_actions_per_hour: 20
    require_second_signal_before_disable: true
    log_every_decision_to: siem

The query that feeds it is the same one a human analyst would run; the agent just runs it on every alert instead of the handful a tired responder gets to:

// Signal the triage agent enriches before it decides
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0
| summarize Locations = make_set(Location), Ips = make_set(IPAddress)
    by UserPrincipalName
| where array_length(Locations) > 1
| join kind=inner (
    AADUserRiskEvents
    | where TimeGenerated > ago(1h)
  ) on UserPrincipalName

Notice what is doing the work here. The model is not the security control. The policy that says "revoke a session on your own, but escalate before you disable an account" is the control, and it is yours to write and defend. Buy the agent, and you still own that file.

The right-sized version for a small team

None of this argues against agentic triage for a small shop. It argues for sequencing. The enterprise SOC gets to bolt an agent onto years of tuned detections and a staffed response function. A small team gets the most out of the same technology by pointing it at the narrow slice where the prerequisites are already met, almost always the Microsoft 365 and Defender estate, where the telemetry, the response actions, and the vendor's own triage agent live in one place.

Start there. Turn the agent loose on one alert class you understand well, phishing submissions or impossible-travel sign-ins, with the autonomous actions scoped to reversible steps and everything destructive set to escalate. Watch its closes for a few weeks the way you would review a new junior analyst's work. If it earns trust on that slice, widen it. The speed is worth having when an attacker can be in and out in 72 minutes, but speed pointed at a blind or ungoverned environment only gets you to the wrong conclusion faster.

Fix the inputs before you rent the analyst

The agentic SOC is arriving whether or not any single team is ready for it, and for defenders that is mostly good news. The mistake is treating it as a substitute for the detection program underneath it. Before you sign, take an honest inventory: what telemetry are you actually collecting, which response actions are wired up and authorized, and who on your team owns the agent's verdicts. If two of those three are missing, the money buys more by fixing them first. If they are in place, pilot narrow, supervise closely, and expand on evidence.

That inventory, what you can see, what you can act on, and who is accountable for it, is the same assessment we run for small teams deciding whether to buy detection tooling or build the foundation for it first. If you want a second set of eyes on where your telemetry and response gaps are before a vendor sizes them for you, that is a conversation worth having.