Before an AI agent touches your SOC queue

Security operations teams have spent two years being told that AI agents will take the alert queue off their hands. Less has been written about what has to be true inside a SOC before that handoff actually works. A survey circulated by Prophet Security, its State of AI in Security Operations 2026 report, puts numbers to both halves of that question: which problems teams are trying to solve, and which pieces of plumbing get in the way.

The survey drew on responses from more than 250 CISOs, SOC leaders and practitioners. Prophet Security pairs it with a five-level framework, the SOC Hierarchy of Needs, that it uses to place readiness questions in context.

Daily use versus daily readiness

The adoption picture the survey describes is close to settled. 40% of security teams now use AI every day, and another 56% are in testing. Only 4% reported no plans to adopt it at all.

That leaves a large group in the evaluation stage, and the question they face is narrower than whether to buy. It is whether their own environment can support an agent that investigates alerts on its own. Prophet Security splits that into two parts: whether a SOC has the problems agents are built to handle, and whether it has the data access, context, written standards and oversight rules an agent needs to reach accurate conclusions.

One point the company makes up front is that a SOC does not have to be far along the maturity scale to be a candidate. Agents do their first work at the bottom layer, alert handling, and the analyst hours they return create room to improve the layers above.

The outsourcing complaints that keep recurring

Prophet Security lists a set of patterns it associates with SOCs that benefit most from agent deployment, separating teams whose alerts are worked by an MDR or MSSP from teams running their own queue.

For outsourced operations, the listed problems include escalations that arrive hours after activity began because the provider is working a queue shared with other customers. Providers may also hand alerts back for lack of context, arriving with a short summary and questions such as whether a login was expected, whether a server is production, or whether a user is traveling. When a provider marks an alert benign, the note may not record what was checked and how the conclusion was reached, leaving the customer either to trust the call or repeat the work. Coverage can also stop at the tools a contract supports, pushing alerts from a SaaS application or a second cloud platform back onto the internal team.

Teams that work their own queue have a different list. Answering "are we impacted?" after a critical vulnerability or a new campaign can take days, because it means hunting across the environment by hand, often by an analyst who is also working alerts. Lower-severity alerts wait or get closed in bulk. Noisy detections get switched off rather than tuned. Hunting and detection engineering wait for spare afternoons. A small number of senior analysts carry the hardest cases. Nights and weekends are thinly staffed.

Prophet Security describes agents as built for this work: starting on each alert as it arrives, whichever tool raised it and whatever the hour, pulling context from the customer's own systems, and recording the evidence behind each conclusion so the team can check it. Some platforms, the company says, can also run a hunt on the day a new threat is disclosed.

Where agents sit on the maturity ladder

The SOC Hierarchy of Needs has five levels in Prophet Security's account: alert management, detection coverage, threat awareness, proactive hunting and posture improvements. Each depends on the one beneath it. A team buried in alerts rarely reaches hunting; a team that hunts without threat awareness has no clear idea what to look for.

Many SOCs have not stabilized the first level. Survey respondents said 28% of their alerts are never investigated. Agents typically start at that first level and, in newer platforms, reach into hunts and proposed detections at levels two and four. The hours they return are meant to be spent above level one.

An agent can only query what it can reach

Because an agent investigates by running queries against a customer's tools, anything it cannot reach is invisible to it. Prophet Security's example: an agent that can query the EDR but not the identity provider can describe what happened on an endpoint but not which account was behind it.

The company breaks readiness here into three pieces.

• API access to the sources an investigation needs, which it says usually means the SIEM, EDR, identity provider, cloud platforms, email and key SaaS applications.
• Readable context, including asset criticality, user roles, VIP lists, business units and known-benign activity such as scheduled scans and admin scripts, so the agent can tell an attacker from a legitimate administrator.
• Healthy data pipelines, monitored for silence or delay, since a missing log source can make an investigation look complete when key evidence is absent.

Prophet Security's suggested test is to take five recent incidents and list every query a senior analyst ran to close them; any query the agent could not run marks a gap to close before a pilot.

Data access also draws the most common objection. 44% of teams cited data privacy and how AI models are trained, the most frequent roadblock respondents named. The company's advice is to ask each vendor whether customer data trains its models and where that data is processed.

Writing down what finished looks like

A pilot needs a written standard to grade an agent against. In many SOCs, Prophet Security notes, only senior analysts hold that standard and it is rarely written down.

Such a standard would cover which evidence closes a phishing case, when an impossible-travel alert warrants a call to the user's manager, and what counts as enough to call an alert benign. Writing it down for the highest-volume alert types, the company adds, doubles as onboarding material for new analysts.

Prophet Security also recommends keeping a list of detections that were switched off. Up to 40% of organizations had turned off some detections because they lacked the people to check them, according to the survey. When an agent investigates every alert, some of those rules can be restored, and the list shows where to start.

The company then asks teams to record the numbers they will compare against: the share of alerts investigated, mean time to investigate, time from alert to first look, and how often closed alerts are reopened. The survey offers two reference figures: a thorough investigation takes an average of 75 minutes, and alerts often wait close to an hour before anyone opens them.

Investigation and action are different risks

Prophet Security draws a line between letting an agent investigate and letting it act, and says most teams treat them differently. In the survey, 57% of teams require a human to review every AI decision before an alert is closed. On response, 44% have AI recommend actions that people carry out, 30% let it handle low-risk remediation on its own, and no respondent gives it full, unsupervised autonomy.

For a SOC to be ready, the company says four rules should be written down before a pilot begins:

• Default approvals: a list of actions that stay human-approved, such as isolating a host, disabling an account or blocking a domain.
• How permissions widen: who can grant the agent more autonomy for a category of action, and what track record they need to see first.
• Where findings land: agent findings should appear in the case management or ticketing tools analysts already use.
• Who owns feedback: a named person reviews the agent's mistakes and turns corrections into guidance for next time.

The company's recommended path is read-only access for investigations first, widening permissions as confidence grows, which it compares to the rules a SOC applies to a new human analyst. Its framework for building trust in an AI SOC follows the same stepwise approach.

How the checklist is split

Prophet Security closes with a yes-or-no readiness checklist, split into a need test and a technical readiness test, with the relevant maturity level marked on each item.

The need test asks whether MDR or MSSP escalations arrive hours late, whether a provider hands alerts back for lack of context, whether it closes alerts without showing what it checked, and whether alerts from outside its coverage land internally. It asks whether telling leadership about impact from a new vulnerability or campaign takes more than a day, and whether low- and medium-severity alerts wait or get closed in bulk. It also asks whether noisy detections have been switched off for lack of tuning time, whether hunting and detection engineering wait for spare time, whether only one or two senior analysts can work the hardest cases, and whether after-hours alerts wait until morning.

The readiness test asks whether a new tool can query the SIEM, EDR, identity, cloud and email sources through an API, and whether asset criticality, user roles and known-benign activity are recorded somewhere a system can read. It asks for a written standard for a complete investigation covering the alert types that make up most of the volume, and for decisions on which actions stay human-approved and who can widen the agent's permissions. It asks whether log-source arrival is monitored, whether the current share of alerts investigated and mean time to investigate are known, whether a list of capacity-related switched-off detections is kept, and whether there is a plan with named owners for the hours an agent returns.

Prophet Security's guidance on sequencing is specific: a "no" on any of the first four readiness items is worth fixing before a production pilot, while the other four can be worked on during it.

Why it matters for teams evaluating a pilot

The practical weight of this material sits with teams that are past the demo stage and deciding what to switch on. The survey's split between daily use and testing suggests a large share of SOCs are heading toward a decision in the near term, and Prophet Security's framing implies that most of the preparatory work is documentation and configuration rather than procurement.

That has a direct consequence for how a pilot gets judged. A SOC that records its baseline metrics and writes down its investigation standard before deployment has something to measure an agent against; one that skips that step may struggle to tell a weak agent apart from a weak data foundation. The vendor questions on model training and processing location are worth asking early, given how often the privacy objection surfaced. And the survey's own response figures, with 57% insisting on human review of every AI decision before closing and no respondent granting full autonomy, suggest that for now most teams want an agent in the analyst's seat, not in the decision-maker's.