Beyond the Runbook: How AI Security Agents Are Reshaping the SOC Playbook

For more than a decade, the security playbook has been the backbone of the modern SOC. Every mature security operations team has invested in them: codified procedures that turn the scattered knowledge of senior analysts into repeatable workflows. Phishing triage, malware containment, suspicious login response, data exfiltration investigation: each gets a SOAR runbook with neatly numbered steps, clearly defined inputs, and predictable outputs.

AI generated content

Playbooks brought order to chaos. They standardized response, reduced mean-time-to-respond, and made onboarding new analysts dramatically easier. But anyone who has spent real time inside a SOC knows the dirty secret: most playbooks fail at the exact moment they are needed most.

This post is about why that happens, and how AI security agents (particularly those grounded in your own security data through RAG) are quietly fixing the gap without throwing playbooks away.

What Playbooks Get Right

Before we critique playbooks, let’s give them their due. The reason playbooks dominated the last decade of security automation is because they solve real problems:

• Consistency. Every alert of a given type gets handled the same way, by the same logic, regardless of which analyst is on shift or what time of night it is.
• Auditability. When a regulator, customer, or internal review asks “what did you do when this fired?”, you have a deterministic answer. Step 1 ran, step 2 ran, step 3 escalated.
• Speed at scale. A SOAR platform can run a containment playbook in seconds across thousands of alerts. No human can match that throughput.
• Knowledge capture. A playbook turns a senior analyst’s intuition into a written procedure, which means the team doesn’t lose institutional knowledge when someone leaves.

These are not small wins. Anyone proposing to replace playbooks is proposing to give up consistency, auditability, and speed. That is not the trade we want to make.

Where Playbooks Break Down

The problem is that playbooks are static graphs running against a non-static world. The same properties that make them powerful (predictability, predefined inputs, predefined outputs) are the same properties that make them brittle.

They assume the input shape. A phishing playbook expects an email with a sender, recipient, subject, body, and maybe an attachment. What happens when the alert comes from a Teams message? A Slack DM? A QR code in a PDF screenshot? The playbook either silently fails or routes everything to the human queue, defeating the purpose.

They cannot reason about novelty. A playbook checking whether a URL is malicious has a fixed list of enrichment sources, typically VirusTotal, URLhaus, and an internal threat intel feed. If all three return “unknown,” the playbook has nothing to say. A human analyst at this point would pivot: “this domain was registered three days ago, it’s hosted on the same ASN as three campaigns we tracked last month, and the cert SAN includes a typosquat of our CFO’s name.” The playbook cannot make that pivot because nobody coded that pivot in advance.

Decision branches multiply unmanageably. Every “if/else” you add doubles the test surface. Real-world investigations have dozens of branching considerations. Trying to encode them all gives you a 400-node monster that nobody on the team fully understands and that breaks every time a vendor changes an API response shape.

They drift. The threat landscape moves weekly. Your playbooks were written eighteen months ago by an engineer who has since left. Half the integrations are deprecated, a third of the IOC sources changed their schema, and the one analyst who knew which steps actually mattered is now at a competitor.

The honest summary: playbooks are great at executing a known response and terrible at deciding what response is appropriate when the situation is even slightly off-script.

Where AI Agents Fit In

This is exactly the gap an AI security agent fills. The framing that has caused the most confusion in the industry is “AI will replace playbooks.” It will not, and it should not. The right framing is much simpler:

Playbooks are good at execution. Agents are good at judgment. Put the agent inside the playbook.

An AI agent, in this context, is not a chatbot. It is an autonomous reasoning component that can be invoked at a node in a playbook, given a goal and a set of tools, and trusted to figure out the steps in between. Where a playbook step says “enrich this IP via VirusTotal,” an agent step says “investigate this IP and tell me whether it’s worth escalating, with evidence.”

That single shift changes the economics of SOC automation.

What an Agent Invocation Inside a Playbook Looks Like

Imagine a phishing-response playbook. The traditional flow looks like:

1. Receive reported email
2. Extract URLs and attachments
3. Check URLs against threat intel feed A, B, C
4. Detonate attachment in sandbox
5. If any indicator is “malicious,” contain; else close as benign

Now insert a single agent node between steps 4 and 5: “Given everything we know so far, decide whether this is a real phishing attempt, and explain why.”

The agent receives the structured outputs of steps 1–4 as context. It also has access to a curated set of tools: your SIEM, your identity provider logs, your email gateway, your threat intel platform, and your historical case database. With that context and those tools, it can do things the static playbook never could:

• Notice that the recipient is a finance executive who received three similar emails over the past two weeks, all from newly-registered domains.
• Pull the last 24 hours of authentication events for the recipient and notice an impossible-travel pattern that started before the email was opened.
• Recognize that the URL, while not on any blocklist, follows the exact lure pattern of a campaign your team documented in a closed case six months ago.
• Conclude with a confidence score, a written rationale, and a structured verdict that the rest of the playbook can branch on.

The playbook still owns containment. The playbook still owns audit logs. The playbook still owns the “did the SLA get met” timer. But the decision (the part humans were doing because no decision tree could express it) is now done by something that can reason over context, in seconds, at every alert.

The Critical Ingredient: Grounding and RAG

Here is where most agent deployments succeed or fail. An agent that hallucinates is worse than no agent at all in a security context, because a confidently wrong verdict is the most dangerous output a SOC tool can produce.

The answer is grounding. The agent must not rely on what a model “knows” from pretraining. It must reason over yourdata: your alerts, your assets, your users, your tickets, your past investigations, your runbooks, your threat intel, your identity graph. Retrieval-augmented generation (RAG) is how this is typically done. At inference time, the agent retrieves the relevant slices of your security data and reasons over them rather than over its parametric memory.

Done well, this means:

• Asset context. When the agent sees an IP, it knows whether that IP is a domain controller, a developer laptop, a print server, or an internet-facing load balancer.
• Identity context. When it sees a user, it knows their role, their normal working hours, their normal geography, and which sensitive systems they touch.
• Historical context. When it sees an indicator, it knows whether your team has investigated it before and what the outcome was.
• Procedural context. When it makes a recommendation, it cites which of your internal runbooks or past tickets shaped the recommendation.

Grounding is what turns the agent from “an LLM with security flavor” into something a SOC manager can actually trust to feed verdicts back into a playbook. Without it, you are automating speculation. With it, you are automating reasoning over your own ground truth.

Where Skills and MCP Come In

Grounding is necessary but not sufficient. Knowing that an IP belongs to a host called dc-prod-03 is useless if the agent has no idea what a domain controller is, why it matters, or what the right next move is when one shows anomalous behavior. The agent needs two things working together: skills (the procedural knowledge of how to investigate something) and MCP-exposed tools (the actual hands that touch your security stack). Enrichment is the connective tissue between them.

Think of it this way:

• RAG gives the agent facts about your environment.
• Skills give the agent know-how, meaning the documented investigative procedures your senior analysts would follow.
• MCP servers give the agent capabilities, meaning the ability to actually query your SIEM, your EDR, your IdP, your CMDB, or your ticketing system in real time.

A realistic agent invocation pulls from all three. Below are some grounded examples of how this looks in practice.

A note on naming: the skill names (investigate-credential-access, etc.) and MCP tool names (cmdb.get_asset, edr.get_process_tree, etc.) used below are illustrative. In your environment they would map to whatever conventions your team and tooling already use. The pattern matters more than the specific labels.

Example 1: “Is this host actually a domain controller, and does that change the response?”

An EDR alert fires for suspicious LSASS access on host WIN-DC-PROD-03. A static playbook would enrich the host against the asset database, get a tag back, and branch. An agent does something more useful.

The agent has a skill called investigate-credential-access that encodes your team's playbook for this exact alert family. The skill tells it: confirm host criticality, check whether the access pattern matches known admin tooling, look for lateral movement precursors, check if the initiating process is signed and expected on this host class.

To execute that skill, the agent calls MCP tools in sequence:

• cmdb.get_asset(hostname) returns role=domain_controller, environment=production, owner=identity-team, criticality=tier-0.
• edr.get_process_tree(host, alert_id) returns the parent process, command line, and signing status.
• siem.search(query, time_range) pulls authentication events from this DC in the last 60 minutes.
• idp.get_recent_admin_changes(time_range) checks whether any privileged group membership changed.
• cases.search_similar(alert_signature) retrieves three closed cases with the same signature, two of which were red-team exercises and one of which was a real incident.

Now the agent reasons: this is a tier-0 asset, the LSASS access came from an unsigned binary in C:\Users\Public\, no scheduled red-team exercise is running, and the closest historical match was the one real incident, not the two exercises. It returns to the playbook with verdict=high_confidence_malicious, recommended_action=isolate_and_escalate_to_IR, and a citation list pointing to each of the records it used.

The playbook node receives that structured output and branches into its tier-0 containment path. The deterministic execution layer has not changed at all. What changed is that the decision feeding into containment was made by something that understood “domain controller” as more than a string tag.

Example 2: “Is this OAuth grant suspicious?”

A user grants third-party app access to their mailbox. The static playbook checks an allowlist; if the app isn’t on it, it queues for human review. Most of those reviews come back benign, and analysts learn to rubber-stamp them, which is exactly when a real malicious grant slips through.

An agent with an investigate-oauth-grant skill calls:

• idp.get_oauth_grant(grant_id) for the full scope list, the publisher, and the consent timestamp.
• idp.get_user(user_id) for role, department, and recent risk score.
• threat_intel.lookup_publisher(publisher_id) to check whether the publishing tenant has been flagged in any consent-phishing campaign.
• email.search_inbox(user_id, time_range) to see whether the user received a consent-phishing lure in the hour before granting access.
• siem.search('oauth_grant', publisher_id, last_30_days) to see whether other users in the org granted the same app.

The agent notices the publisher tenant was registered eleven days ago, the user is in Finance, the granted scopes include Mail.ReadWrite and offline_access, and a phishing email impersonating DocuSign hit the user's inbox forty minutes before consent. No other user in the org has granted this app. It returns verdict=likely_consent_phishing, with the lure email ID, the grant ID, and a recommended revocation action.

The playbook then revokes the grant, kills active sessions, and opens a case, all using its existing deterministic steps. The agent did not execute any of those state-changing actions itself; it just made the decision well.

Example 3: “Should we contain this endpoint?”

A laptop generates a beacon-like network pattern. Containing it is disruptive. If it’s a developer laptop running a CI agent, you’ve just broken a build pipeline and annoyed a senior engineer. If it’s a finance workstation, you may have just stopped an active exfiltration. The static playbook usually punts to a human.

The agent’s assess-containment-impact skill chains:

• cmdb.get_asset(hostname) for owner, role, and business unit.
• hr.get_user_context(owner) for role and whether they're on-call or in a critical window (e.g., quarter-end close for finance).
• edr.get_network_connections(host, time_range) for the destinations and protocols in question.
• threat_intel.lookup_destinations(ip_list) for reputation on each beacon target.
• network.get_dns_history(host, time_range) to see what was resolved leading up to the beacons.

If the destinations are a known package mirror and the host is tagged as a build agent, the agent returns verdict=benign_developer_traffic with evidence. If the destinations are newly-registered domains with no legitimate purpose and the host belongs to a finance controller during quarter-end, the agent returns verdict=high_priority_contain with a clear business-impact note for the on-call.

Same alert. Same playbook structure. Wildly different decisions, each justified.

Why MCP Specifically

You could of course build all of this with custom integrations and hardcoded API clients, and many teams have. The reason MCP matters is that it standardizes how the agent discovers and calls tools, which means new tools can be added without rewriting the agent and access can be governed centrally. Your CMDB, your EDR, your IdP, your ticketing system each expose an MCP server with a defined set of operations and scopes. The agent picks up those tools at runtime, with the permissions you’ve granted it, and uses only the ones relevant to the skill it’s executing.

This matters operationally for two reasons. First, it means you can constrain what the agent is allowed to do per playbook node: an agent invoked in a triage step gets read-only MCP tools, while one invoked in an enrichment-only context never sees the containment APIs at all. Second, it means as your stack evolves (you swap EDRs, add a new SaaS log source, deprecate an old SIEM) the agent picks up the new tools without playbook rewrites. The skills stay stable; the tools underneath change.

Enrichment, in this model, stops being a fixed set of API calls baked into a playbook and becomes a capability surface the agent draws from based on the situation in front of it. That is the shift that makes the agent genuinely useful inside a playbook rather than just a flashy add-on.

How the Agent’s Output Helps the Playbook Decide

The handoff back into the playbook matters as much as the invocation. A well-designed agent node returns structured output, not prose: a verdict, a confidence score, a list of supporting evidence with links, and a recommended next action. The playbook then does what playbooks do best, branching deterministically on those fields.

This preserves everything that made playbooks valuable. The audit trail still exists. The SLA timers still tick. The escalation paths are still explicit. Nothing about the post-decision flow changes. What changes is that the decision feeding into the flow is now informed by orders of magnitude more context than a static enrichment chain could ever provide.

In practice, this is what teams find: the playbook becomes simpler, not more complex. Many of the brittle if/else branches that existed only to handle edge cases collapse into a single agent node. The playbook gets shorter, the false-positive rate drops, and the analysts spend their time on the genuinely novel cases the agent flags for human review.

A Practical Way to Start

For teams considering this pattern, a few hard-won pieces of advice:

Start with a single, well-scoped invocation point in one playbook. Phishing triage and alert deduplication are good candidates because the cost of a wrong decision is bounded and the volume is high enough to see results quickly.

Insist on grounded retrieval from day one. If the agent cannot cite the specific log, asset record, or past case it used to reach a verdict, it is not ready to feed your playbooks. Provenance is non-negotiable.

Keep the agent’s tools narrow and the goal narrow. An agent told to “investigate this alert” with twenty tools will wander. An agent told to “decide whether this URL is malicious, using these four tools, and return a verdict with evidence” will perform.

Treat the agent’s output as a recommendation, not a command, until you have run it in shadow mode against a few hundred real cases and validated agreement with your senior analysts.

The Real Picture

Security playbooks are not going away, and they should not. They are the right tool for the predictable parts of SOC work, and the predictable parts are most of the work. What is changing is that the unpredictable parts (the judgment calls, the context-heavy decisions, the moments where a static graph runs out of options) no longer have to fall through to the human queue by default.

An AI agent invoked at the right node, grounded in your own security data, with a narrow goal and a structured output, gives the playbook a kind of intelligence it never had: the ability to reason about a situation it was not specifically programmed for. That is not a replacement for the playbook. It is the missing piece that makes the playbook actually work in the messy, novel, off-script reality of modern security operations.

The teams getting this right are not throwing out their SOAR. They are turning their playbooks into thinner, smarter orchestrators around agent-driven decisions. The result is fewer rules, better outcomes, and analysts who spend their time on the work only humans can do.