Agentic AI in the SOC Guide: Autonomous Triage, Investigation and Response

Once a SOC lets AI agents pick up alerts, run queries and trigger containment on their own, the agents become production systems with privileged access, and most SOCs still manage them like a chat assistant someone switched on. The hard questions stop being "is the model clever enough" and become operational: who owns each agent, which tools it may call under which identity, how its skills and prompts are versioned and tested, how work is handed between agents and analysts, and what happens when an attacker writes the text the agent reads. This guide covers the operating model for an agentic SOC: agent roles and workflow design, skills and runbooks managed as code, tool and privilege design, change control and evaluation pipelines, run-time monitoring, cost and failure modes. It is for SOC managers, detection engineers and security architects who already understand AI triage basics; the patterns, autonomy levels and accuracy evaluation are covered in the AI SOC Guide and are not repeated here.

Key takeaways

• Treat each SOC agent as a service with an owner. Register it with a named owner, a purpose, the tools it may call, the identity it runs under and the actions it may take without approval, and review that record like any privileged service account.
• Put skills, prompts and playbooks in version control. Agent instructions are detection and response logic; they need pull requests, peer review, test cases and a rollback path, exactly like detection rules.
• Enforce privilege outside the model. The model chooses a tool, but the tool gateway, the identity provider and the target API decide whether the call is allowed. NCSC describes LLMs as inherently confusable deputies, so a guardrail written in the prompt is not a control.
• Split reading from acting. Investigation agents that read attacker-controlled data should hold read-only credentials; write actions go through a separate, narrow executor with approval gates and deterministic playbooks.
• Measure the agent pipeline, not only the verdicts. Track tool-call failures, denied actions, escalation quality, cost per case and regression test results on every change, alongside the false negative sampling the AI SOC Guide describes.

From AI features to an agentic SOC operating model

An agentic SOC is not one product. It is a set of cooperating agents, each with a narrow job, connected to the SIEM, EDR, identity platform, ticketing system and threat intelligence through tools, and supervised by analysts who handle escalations and approve higher-risk actions. The shift that matters is from "an assistant answers an analyst" to "work moves through agents without an analyst starting it". That shift changes what has to be engineered.

Most organisations end up with a hybrid: agents handle enrichment, triage and investigation at volume, while deterministic SOAR playbooks execute approved actions. See the SOAR and Security Automation Guide for the playbook side and the SOC Guide for the wider operating model.

Designing agent roles and the workflow between them

A single "do everything" SOC agent is hard to evaluate and has the union of every permission it might need. Narrow roles are easier to test, cheaper to run and safer to hijack.

Handoffs and escalation

• Structured handoff: each agent passes a structured case record (entities, evidence links, queries run, verdict, confidence, open questions), not free text. Downstream agents and analysts should be able to re-run every query from the record.
• Escalation triggers: define them in configuration, not in the prompt. Typical triggers are privileged or service accounts, crown jewel assets, any request for a write action outside the approved list, tool errors, and low confidence.
• Loop limits: cap the number of tool calls, agent-to-agent handoffs and minutes per case. A case that hits a limit goes to a human, which also contains runaway cost (OWASP LLM10:2025 Unbounded Consumption).
• Human approval: the approver sees the proposed action, the evidence, the target and the blast radius before approving, in the case tool rather than a chat window. See the Human-in-the-Loop for AI Agents Guide.

SOC-as-code: skills, prompts and playbooks under version control

Detection engineering teams already manage rules as code, for example Sigma rules: YAML files with required title, logsource and detection fields, a status (stable, test, experimental, deprecated, unsupported), a level and ATT&CK tags, converted to SIEM queries with tools such as sigma-cli. The agentic SOC extends the same discipline to agent logic. See the Detection Engineering Guide.

• Skills: packaged task instructions an agent loads when relevant, such as "triage an impossible travel alert" or "investigate a suspicious OAuth grant". The open Agent Skills format, for example, is a directory with a SKILL.md file holding a required name and description, Markdown instructions, and optional scripts/, references/ and assets/ folders, plus an experimental allowed-tools field. Whatever the format, a skill is executable logic and needs the same review as a playbook.
• System instructions and policies: the agent's role, escalation rules and output schema. Keep them in the repository, not only in a vendor console.
• Tool definitions: the list of tools, their parameters and their descriptions. A changed tool description changes agent behaviour, so treat it as code.
• Evaluation cases: labelled historical alerts (true positives, benign, ambiguous) and adversarial cases with injected instructions, stored next to the skill they test.
• Model and configuration pins: record the model version, temperature and tool set for each release so a verdict can be reproduced later.

A change pipeline for agent logic

1. Author changes a skill, instruction or tool definition in a branch.
2. Automated checks run: schema validation (for Agent Skills, the skills-ref validate tool), secret scanning, and a check that no new tool or permission was added without a reviewer from the platform team.
3. The evaluation suite runs against the change: verdict accuracy on labelled cases, missed true positives, behaviour on prompt injection cases, tool calls per case and cost per case.
4. A peer reviews the diff and the evaluation report; changes that add write tools need a second approver.
5. Release to a shadow mode where the agent's verdicts are recorded but not acted on, then to a canary share of alert volume.
6. Roll back by redeploying the previous tagged release. Keep the previous version deployable for at least one full on-call rotation.

The joint NSA, CISA, FBI and Five Eyes guidance on deploying AI systems securely calls for a full evaluation whenever a model is updated before it is redeployed. Model upgrades pushed by a vendor count: ask for advance notice and run your suite before the new model handles live alerts.

Tools, identities and privilege

Every tool an agent can call is a capability an attacker inherits if the agent is steered. OWASP LLM06:2025 Excessive Agency names the three root causes: excessive functionality, excessive permissions and excessive autonomy. Design against each one.

Connecting tools through MCP

Many SOC agents now reach the SIEM, EDR and ticketing systems through Model Context Protocol servers. The MCP authorisation specification (2025-06-18) bases HTTP transport authorisation on OAuth 2.1, requires clients to send the RFC 8707 resource parameter, requires servers to validate that tokens were issued for them, and forbids servers from passing a client's token through to downstream APIs. In SOC terms: each MCP server should get its own audience-bound token, never the agent's broad SIEM credential. Inventory every MCP server your agents use and pin its version; see the MCP Gateway and MCP Server Governance Guide.

Where identity fits

SOC agents are among the most privileged non-human identities in the organisation: they read every log source and can often revoke sessions or isolate hosts. Give them lifecycle management (owner, creation ticket, quarterly access review, decommissioning), keep their credentials in a vault, and alert on any use of an agent identity outside its tool gateway. A stolen agent token used directly against an API looks like valid account use (T1078.004 Cloud Accounts, T1550.001 Application Access Token), so baseline where each agent identity normally connects from. See the Agentic AI Identity Guide.

Untrusted data inside the pipeline

A SOC agent's inputs are written by attackers more often than any other agent's: phishing email bodies, process command lines, user agent strings, file names, DNS queries, ticket text and threat intelligence feeds. NCSC's position is that prompt injection may never be fully mitigated in the way SQL injection was, because an LLM has no built-in separation of data from instructions, and that an LLM processing content from a party should not hold more privilege than that party. The practical consequences for pipeline design:

• Quarantine raw content: the agent that reads raw email or command lines produces a structured summary; it does not also hold write tools. Wrapping external content in clear delimiters helps, but NCSC warns against relying on deny-lists or products that claim to stop injection.
• Check tool calls against the case: a triage agent working an alert about host A should not be able to query or act on host B. Bind tool calls to the case's entities in the gateway.
• Treat tool output as untrusted too: data returned by an MCP server or enrichment API can carry instructions. The Sentry MCP Agentjacking research showed attacker-written error events, delivered through an MCP server, steering coding agents to run commands; SOC telemetry has exactly the same property, because attackers can write log content.
• Vet the tools themselves: the postmark-mcp malicious MCP server worked normally for fifteen versions before one release silently copied outgoing email to an attacker. An MCP server or plugin runs with the agent's delegated access.
• Log failed and denied tool calls: NCSC notes that failed tool calls may show an attack being refined.

Relevant MITRE ATLAS techniques are AML.T0051.001 Indirect LLM Prompt Injection, AML.T0053 AI Agent Tool Invocation, AML.T0086 Exfiltration via AI Agent Tool Invocation and AML.T0080 AI Agent Context Poisoning. See the Prompt Injection Guide.

Implementing an agentic SOC in phases

1. Inventory and baseline (weeks 1 to 4): list every AI feature already switched on in SIEM, EDR, email security and ticketing tools, and the identity each uses. Record current mean time to triage, escalation rates and analyst hours per alert class.
2. Build the platform controls first: agent registry, tool gateway with policy checks, per-agent identities, vault-issued credentials, and logging of prompts, tool calls, outputs and actions to a store the agents cannot write to.
3. Shadow mode for one alert class: pick a high-volume, checkable class such as user-reported phishing. Agents produce verdicts that analysts compare with their own for two to four weeks.
4. Limited autonomy: allow automatic closure of benign cases in that class only, with weekly sampling of closed cases and seeded known true positives.
5. Add investigation agents: read-only hunting with query budgets, producing case summaries for analysts. Measure analyst time saved and the rate at which analysts correct agent conclusions.
6. Add response through playbooks: agents propose actions; deterministic playbooks execute them after approval. Start with reversible actions such as session revocation and host isolation on workstations.
7. Expand by class, not by enthusiasm: each new alert class repeats shadow, limited autonomy and review. Privileged accounts, servers and OT stay on recommend-only longest.

Rollback: every agent has a kill switch that returns its alert classes to the analyst queue without losing cases, tested in a drill each quarter. Removing an agent's write scopes must be possible in minutes through the identity provider, independent of the agent platform.

Decision guidance

• Vendor-embedded agents or your own: agents built into a SIEM or XDR platform are quicker to deploy and already integrated, but their skills, prompts and models change on the vendor's schedule and evaluation is harder. Agents you build on an orchestration framework give you version control and testing but make you responsible for the platform controls. Many SOCs use embedded agents for summarisation and their own for triage logic tied to local context.
• Single agent or multi-agent: a single agent with many tools is simpler to start with; split it once you need different permission levels, as soon as any write action is involved.
• Autonomy per alert class: autonomous closure suits high-volume classes with ground truth you can check later; recommend-only suits rare, high-impact or ambiguous classes.
• Small SOCs and MSSP customers: you may not run your own pipeline. Ask your provider for the agent register, the evaluation results for each release, the identities their agents use in your tenant, and how you can revoke them. Contractual notice of model changes matters more than features.
• Large SOCs: create a small SOC platform team that owns the registry, gateway, evaluation suite and release process, separate from the analysts who write skills, so no one approves their own agent's permissions.

Monitoring the agents and measuring the pipeline

Log enough to reconstruct any case: the triggering alert, every prompt and tool call with parameters, every tool result reference, the model and skill version, the verdict, any approval, and the final action. The joint deployment guidance calls for logging inputs, outputs, intermediate states and errors with automated alerts. Send agent logs to a separate tenant or index with retention matching your incident records; an attacker who hijacks an agent should not be able to edit its trail. See the AI Agent Observability and Incident Response Guide.

What to alert on

• A tool call denied by the gateway, especially a write action or an out-of-case target.
• An agent identity authenticating from outside its gateway or runtime network.
• A sudden change in auto-closure rate for an alert class (attackers who learn what agents close will try to look like it).
• Tool-call or token volume per case far above baseline.
• Changes to skills, tool definitions or agent permissions outside the release pipeline (T1685 Disable or Modify Tools applies when an attacker tampers with security tooling).

Metrics

See the Security Operations Metrics Guide for the wider SOC metric set.

Framework mapping

Common failure patterns

• Prompt-level guardrails as the only control: "never disable executive accounts" in the system prompt, with the agent holding a token that can. Enforce it in the gateway and the identity provider.
• One shared AI service account: every agent and every vendor feature uses the same broad credential, so no action can be attributed and nothing can be revoked selectively.
• Skills edited live in a console: a well-meant prompt tweak changes closure behaviour for thousands of alerts with no test, review or record of what changed.
• Silent vendor model changes: the platform upgrades its model, verdicts drift and nobody notices because there is no regression suite or per-release metric.
• Readers that can write: the agent that parses phishing bodies also holds mailbox purge rights, so one crafted email can steer a destructive action.
• Unbounded loops: an investigation agent keeps querying on an ambiguous case, burning budget and SIEM capacity, because no per-case limit exists.

Practitioner checklist

• Maintain a register of every SOC agent with owner, purpose, tools, identity, autonomy level and review date.
• Store skills, system instructions, tool definitions and evaluation cases in version control with peer review.
• Run a regression and prompt injection evaluation suite on every skill, tool or model change before release.
• Give each agent role its own identity with short-lived, scoped credentials; no static keys in configuration.
• Keep agents that read attacker-controlled content read-only; route write actions through approved playbooks.
• Enforce authorisation, case binding and per-case limits in a tool gateway, not in prompts.
• Inventory and pin every MCP server and plugin, with audience-bound tokens per server.
• Log prompts, tool calls, results, versions and approvals to a store agents cannot modify, and alert on denied calls.
• Test each agent's kill switch and credential revocation in a quarterly drill.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: SP 800-53 Rev. 5
• NSA, CISA, FBI and partners: Deploying AI Systems Securely
• NCSC: Prompt injection is not SQL injection (it may be worse)
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATLAS: AI Agent Tool Invocation
• Model Context Protocol: Authorization specification
• SigmaHQ: Sigma rules documentation

Related NHI Mgmt Group resources: AI SOC Guide · SOC Guide · SOAR and Security Automation Guide · Top 10 SOC Challenges · Agentic AI Security Guide