Agentic AI maturity for security operations teams
Security operations maturity for AI agents is how far agents run the prepare, detect, investigate, respond, recover and improve loop, and whether runtime policy can stop a high-impact response action that the incident does not justify.
Agentic AI maturity for a security operations team is how much of the prepare, detect, investigate, respond, recover and improve loop an agent runs without a person, and whether runtime policy can stop a response action that the incident does not justify. Detection is usually automated long before response is, and that gap has a specific name in this function: the team can see the incident faster than it can safely act on it.
That asymmetry is the whole risk profile of a SOC agent. A wrong detection costs an hour of analyst time. A wrong isolation, credential revocation or firewall block costs a service.
The quick win: score respond and recover before you automate them
Open the security operations track and answer the 20 questions about the workflow you actually run. Then read two things rather than the total.
- The phase scores for respond and recover. If they are 0 or 1 while detect and investigate are 2, stop automating detection further. The constraint is on the action side.
- The two control questions. The first asks what proof the execution layer verifies before a high-impact response or recovery action. The second asks whether policy can block a sequence whose combined effect exceeds the incident's authority.
An afternoon of honest answers tells you whether your next quarter belongs to detection quality or to response safety. It is usually the second.
The six phases, at each level
| Phase | Level 1, a person prompts | Level 2, an agent runs it | Control that has to exist |
|---|---|---|---|
| Prepare | Analyst asks for a summary of asset and owner records | Inventory and dependency changes trigger reconciliation | Scope the agent cannot widen on its own |
| Detect | Analyst asks for a triage suggestion | Agent triages and correlates every alert | Recorded reason for suppression and escalation |
| Investigate | Analyst asks for a timeline | Agent builds the timeline and pulls the evidence | Provenance for every source the agent read |
| Respond | Analyst asks what to do, then does it | Agent performs the containment action | Verified proof before a high-impact action |
| Recover | Analyst runs the restore from a runbook | Agent runs and verifies the restore | Approval with an owner, and a check that it worked |
| Improve | Analyst asks for lessons learned | Agent updates detections from resolved incidents | A change record for the rule it changed |
The middle of that table is where most programs sit: level 2 in detect, level 1 in investigate, level 0 or 1 in respond. Read that way, a score is a statement about which part of the loop is human-paced, and the honest follow-up is whether the human pace is deliberate or accidental.
Why respond is the hard phase
Containment actions are irreversible in the way that matters: revoking a credential logs out every session that used it, isolating a host stops the work happening on it, and blocking a domain breaks whatever depended on that domain. Each action is a small outage, and an agent that takes one on a hallucinated reason causes an incident while responding to one.
The evidence on agent behaviour under adversarial pressure is the reason to keep response gated. In the largest public agent red-teaming competition, 1.8 million attacks produced more than 60,000 successful policy violations across 22 frontier agents, and the authors report that nearly all agents violate policy for most behaviours within 10 to 100 queries (Gray Swan and UK AISI, arXiv 2507.20526). An agent handling alert content is an agent reading attacker-influenced text, which is the definition of untrusted input.
Prompt injection is not a solved problem, and the UK authority says so plainly: current models "simply do not enforce a security boundary between instructions and data inside a prompt", and injection "may never be totally mitigated in the way that SQL injection attacks can be" (NCSC). A SOC agent's whole job is to read hostile content and act. The control has to sit between the reading and the acting.
The two control questions, in SOC terms
What proof must the execution layer verify before a high-impact response action? The answer that scores 2 is not "the agent was confident". It is evidence the execution layer checks itself: a signed artifact, an exact revision, a ticket state, an incident severity an approver set. Alyria's gates verify evidence outside the model, so the action cannot proceed on the model's own say-so.
Can policy stop a sequence whose combined effect exceeds the incident's authority? Individual actions often pass. Isolating one host is fine; isolating the cluster that runs the payment system is not. Reading a credential inventory is fine; reading it and then opening an outbound connection is exfiltration. Only a rule that sees session state can tell those apart, which is what an information-flow-aware policy engine does. Lyra is capability-brokered and tracks data classification as it moves through the agent's context, so a tool can be allowed in general and one call still denied.
Tooling risk the SOC inherits
A SOC agent is a client of many systems, and MCP servers are how most of those connections now arrive. The numbers are unflattering: across 20 agents tested against 45 live MCP servers, the highest attack success rate reached 72.8 percent and no model refused more than 3 percent of attacks (MCPTox, arXiv 2508.14925). At the client end, the mcp-remote package carried an OS command injection flaw rated 9.6 when connecting to untrusted servers (CVE-2025-6514), and a zero-click prompt injection in a productivity assistant was rated 9.3 as an information disclosure (CVE-2025-32711).
The practical consequence for maturity: an inventory that lists agents but not the servers they trust cannot score above 1 on either control question. Alyria Beacon inventories the AI toolchain on each endpoint, including the MCP servers each client is wired to, and flags down-level tools, unpinned servers and secrets in config.
Getting the signal into the SOC's own pipeline
A SOC governs what it can see in its own tools. Agent decisions that live in a vendor console are outside the detections, correlation rules and retention the team already trusts.
Spectra collects OpenTelemetry from every Beacon and routes it to Observatory or straight into your SIEM, so policy decisions, MCP activity and inventory land in the same pipeline as the rest of the estate. The audit chain behind those decisions is signed and hash-chained, which matters when the question is not what happened but whether the record can be relied on in a review.
A sequence that works
- Score the loop, and accept that respond and recover are the constraint.
- Inventory endpoints and MCP servers, and keep the inventory current.
- Write two response rules: no containment action without a verified approver on the incident, and no containment action on a host outside the incident's declared scope.
- Run both in monitor mode for a week. Read the decisions. Expect the first version to be wrong about scope.
- Promote enforcement one action category at a time: block, then isolate, then revoke.
- Move recover last. It has the lowest error tolerance and the highest cost of an interruption.
- Keep the decisions in the same record as the incident, so the review has one timeline.
Frequently asked questions
Should a SOC agent ever isolate a host on its own?
Only with an evidence gate that the execution layer checks, and only within a scope an approver set. The gate is what makes autonomy defensible, and it is the difference between level 1 and level 2 on the respond questions.
Where does the agent's authority come from?
From the incident, not from the model. An incident has a severity, an owner and a scope, set by a person or by a policy that a person wrote. Policy should refuse any action outside that scope, including a sequence of individually small actions whose combined effect is larger.
Is detection automation the same as maturity?
No. Detect is one phase of six. A team at level 2 in detect and level 0 in respond is fast at seeing and slow at acting, and it will spend its time in manual containment while the queue grows.
How do we keep the SIEM useful?
Send agent decisions and MCP activity to it in OpenTelemetry rather than leaving them in vendor consoles. Spectra does that from every Beacon, and the same signal feeds Observatory for the fleet view.
Do the free assessments cover the whole SOC?
The security operations track covers one team's loop across the six phases plus the two controls, in 20 questions. Organization-wide scoring runs the same packs in Compass, with dated instances per contact and per-division summaries.
Get a full Alyria maturity assessment
Alyria assesses your agents and controls across functions using Compass (compass.alyria.ai), and delivers a scored maturity report and a roadmap. Talk to us about a full assessment, or read what each level expects of inventory, policy, monitor mode, audit and approvals in the agentic AI maturity model at alyria.ai.