Author: Elirez Oved, Senior Cloud Security Consultant
For any enterprise security team, the prime directive has always been simple: stay one step ahead of the adversary. But recently, threat intelligence from Mandiant's M-Trends 2026 Report has observed a shift: adversaries have moved from experimenting with AI to operationalizing it, deploying adaptive malware that rewrites its own code and queries LLMs mid-execution to evade detection. AI has become an incredibly potent weapon for the offense - accelerating the speed and scale of attacks, which begs the ultimate question: Are defensive teams keeping pace, or are we already falling behind?
Look no further than our own defensive stack. Today, many modern security platforms - with Google Security Operations leading the charge - already come equipped with powerful, built-in AI capabilities. Yet, facing this surge of automated threats, security leaders must ask themselves: Are we truly maximizing the full potential of these investments? To truly outpace advanced adversaries, we need to move past standard chatbot sidebars and inject protocol-driven, agentic architectures directly into our environments. In other words, we must transition from AI that simply talks to us, to AI that safely works for us.
In my previous post, I explored how the Model Context Protocol (MCP) acts as an open standard, allowing an LLM like Claude to directly interface with Google SecOps. If you haven't read it yet, MCP is essentially an open-source protocol that creates a secure, universal bridge between AI models and external tools and data sources. Today, we are taking the next logical step. We aren't just talking about a single AI chatbot using tools. We are going to dive deep into building a structured, hierarchical Agentic System - moving from core individual Skills, to specialized security-focused Sub-Agents, managing autonomous Agent Goals, and scaling up to collaborative Agent Teams.
Defining the Agentic Spectrum
The term "agent" has become increasingly broad, often describing everything from simple tool-calling workflows to highly autonomous systems. Rather than treating agency as a binary concept, it is often more useful to think in terms of an agentic spectrum, where systems exhibit different levels of autonomy, reasoning, environmental interaction, and goal-directed behavior. To build a robust security architecture that can operate in a modern threat landscape in Claude Code, we can break this spectrum into four practical operational layers:
Tools (The Capabilities): The foundational building blocks that allow an AI system to interact with the outside world. In a SecOps environment, these include Google SecOps MCP tools, Google Threat Intelligence lookups, case management actions, search capabilities, and external security platforms.
Skills (The Methodology): Reusable, task-specific playbooks that define how tools should be used to accomplish a particular objective. Skills capture organizational knowledge, investigation procedures, and analyst workflows, enabling consistent execution across tasks (e.g., a Google SecOps alert triage methodology or a phishing investigation playbook)
Agents (The Autonomous Operators): Systems that combine reasoning, memory, tools, and skills to pursue objectives with varying degrees of autonomy. Rather than following a fixed workflow, agents can evaluate context, select appropriate skills, choose tools, and adapt their approach based on intermediate results (e.g., autonomously investigating a suspicious user across UDM logs and Google Threat Intelligence).
Multi-Agent Patterns (The Coordination Layer): As tasks become more complex, multiple agents can be coordinated to work toward a shared objective. Common patterns include delegated sub-agents, where a lead agent assigns specialized tasks to focused execution units, and agent teams, where multiple agents collaborate to solve problems in parallel (e.g., one agent researching a new CVE while others assess internal exposure and generate detections).
A Note on the Agentic SecOps Spectrum: Turnkey vs Custom
Before we dive deep into building custom capabilities from scratch, it’s important to understand the broader Agentic SecOps spectrum. Google Cloud Security already does some heavy lifting right out of the box. Google SecOps includes turnkey, in-product agents - like specialized Triage, Malware, Threat Hunt, and Detection Engineering Agents - engineered to deliver deterministic, high-quality results directly inside the product UI.
But a true next-generation SOC operates in a multi-vendor environment. You have third-party identity providers, specific firewalls, endpoint tools, and cloud perimeters that live outside a single pane of glass.
That is where the other side of the spectrum comes in: Building your own agentic components. By leveraging open-source frameworks, Model Context Protocol (MCP) clients (like Claude Code, Gemini CLI, Cline, or the ADK), and connecting them to both 1st-party Google tools (SecOps, GTI) and 3rd-party interfaces (Wiz, CrowdStrike, Okta), you can extend agentic capabilities across your entire security matrix.
In this article, our focus is entirely on this DIY side of the spectrum - learning how to orchestrate your own custom ecosystem, starting with Skills.
While we are using Anthropic’s Claude to build and demonstrate these patterns throughout this article, it is important to note that these core architectural principles are model-agnostic. With minor adjustments to prompts and tool calling, almost any advanced LLM can support this framework. The magic isn't tied to a single model - it's in how you orchestrate these patterns to defend your environment.
1. Skills: The Modular DNA of Your SOC
If you hire a new SOC analyst on Monday, you don't just hand them access to Google SecOps and say, "Go hunt threats." You give them your internal playbooks. You teach them your specific false-positive checks, your team's unique escalation paths, and the tribal knowledge that lives inside your senior analyst's head.
When you connect an LLM to your tools via MCP, it has the raw capabilities (Tools), but it lacks your methodology (Skills). To put it simply: Tools represent what Claude can do (e.g., search_entity), while Skills define when to use the tool and how your specific team wants it done.
If you've ever built a basic LLM automation, you know the pain of writing massive system prompts packed with operational instructions like "check this log, then query this tool, then format the response this way." Before long, those same instructions end up duplicated across multiple prompts, workflows, and use cases, making them difficult to maintain and evolve.
This is exactly where Skills come in. Rather than embedding your team's methodology into every prompt, Skills package that knowledge into reusable modules that can be invoked whenever needed. You define the process once and apply it consistently across investigations
Beyond maintainability, Skills help standardize investigations across the SOC by ensuring the same methodology is applied every time, reducing analyst-to-analyst variation and minimizing human error. Through progressive disclosure, Claude initially loads only a lightweight description of the Skill and retrieves the full implementation only when required. This reduces unnecessary context consumption while keeping detailed operational guidance available on demand.
Under the hood, a Skill is built on platform-agnostic Agent Skills specification. It is structured as a version-controlled directory containing a core SKILL.md file, paired with supporting templates or reference documentation.
The Skill Directory Structure
google-secops-triage/
├── SKILL.md
├── reference/
│ └── known-good-service-accounts.md
└── templates/
└── incident-summary-template.md
Writing the SKILL.md
The file begins with specific YAML frontmatter. To protect your context window, Claude utilizes a concept called progressive disclosure. This means that at the start of a session, Claude only scans a lightweight, high-level description (~100 tokens) of the skill. The detailed markdown playbook is only loaded when the skill is actually invoked, reducing context overhead while keeping detailed operational guidance available when needed.
---
name: google-secops-triage
description: Use this skill when investigating high-severity alerts in Google SecOps or analyzing raw UDM logs for abnormal user execution. Triggers on multi-stage authentication alerts or suspicious administrative activity.
---
# Google SecOps Triage Methodology
## Step 1 — Extract UDM Indicators
- Parse the raw UDM (Unified Data Model) event payload.
- Extract target user, source IP, credential type, and targeted resource.
## Step 2 — Enrichment via Google Threat Intelligence (GTI)
- Extract all external network entities from the alert.
- Cross-reference source IPs against GTI malicious reputation bounds.
- Query historical case logs within Google SecOps for the same user asset over the last 90 days.
## Step 3 — Scope Verification
- Because Skills run in a secure code execution sandbox, Claude has file-system access. Query `reference/known-good-service-accounts.md` to check if the affected asset belongs to an excluded test environment.
- Validate if the event conforms to a known scheduled change window.
## Step 4 — Verdict Formulation
- Categorize explicitly: True Positive | False Positive | Benign | Escalation Required.
- Mandatorily append the specific UDM field strings that justified the classification.
Time for a Hands-On Test
It is time to test the Google SecOps MCP setup and run through some practical validations. If we run the /skills command in the Claude Code CLI, we can verify all the available skills currently loaded into our environment. We can see our newly created google-secops-triage skill ready to go:
When prompted, the LLM uses the YAML frontmatter to identify and automatically load the relevant skill.
And here, in less than a minute, we get a full, deep-dive investigation tailored exactly to our specified skills demands, returning a Benign verdict. The model explains that Case 894 contains two GCP GCE Instance Deletion alerts that are actually part of a single, automated internal platform pipeline initiated by a Google-managed service agent:
To truly prove the resilience of this setup, I stress-tested the agent by planting a couple of intentional mistakes in the scenario-such as removing the reference list entirely. I wanted to see if the LLM would lazily try to satisfy my request or hallucinate a passing grade. Instead, it passed the test perfectly: it caught the anomalies, flagged the missing reference data, and explicitly refused to validate the data without that file.
By encapsulating methodology this way, your senior analysts' expertise becomes code. The workflow vs. agent distinction clicks instantly here: An AI workflow invokes a skill at a rigid, predefined step. An AI agent reads its environment, notices an alert involving a complex Google SecOps log stream, and autonomously decides to load the correct skill on its own.
2. Specialization: From Skills to Google SecOps Sub-Agents
Skills help package expertise into reusable modules, but complex investigations can still accumulate significant context within a single agent session. As an agent performs threat research, log analysis, exposure validation, and remediation planning, it must retain the reasoning, observations, and intermediate findings from each task. Over time, this growing context can dilute focus and consume valuable context-window resources.
In an enterprise SOC, you wouldn't expect a single analyst to simultaneously perform malware research, hunt through log data, validate exposure, and develop response actions while keeping every detail in working memory. You specialize.
In our agentic architecture, we scale out by establishing Sub-Agents. Rather than running a single, massive conversation loop, the main orchestrator dynamically delegates tasks to separate execution contexts, each optimized for a specific domain and equipped with the tools and skills required for that mission. Each Sub-Agent performs its work independently and returns only the relevant findings to the orchestrator, reducing context overhead while maintaining visibility into the overall investigation.
This design pattern relies on a strict hierarchical delegation topology:
Context Isolation: Sub-agents run inside separate, dedicated sessions. By stripping away the conversational history and "noise" of the parent agent, they reduce token overhead, keeping the focus entirely on the task at hand.
Least-Privilege Tooling: Sub-agents only see the narrow tools explicitly declared in their configuration. A threat researcher agent can query intelligence databases, but it completely lacks the access permissions required to modify live SIEM detection rules.
Zero Lateral Chat: Sub-agents never communicate horizontally with each other. They execute their specific instruction set and report their findings directly back up to the manager.
The Sub-Agent Architecture in Action
To see this setup in action, let's examine the local environment. Within the claude/agents/ directory, we define specialized sub-agents, configuring each with distinct markdown playbooks, explicit responsibilities, and dedicated MCP tools:
To test this orchestration ecosystem, I tasked it with the ultimate stress test for any team: a brand-new, zero-day CVE announcement! I launched the soc-shift-manager agent using the following prompt:
"We have discovered that several internet-facing servers are vulnerable to CVE-2025-5777. Investigate the threat, identify whether we are exposed, determine the severity, and recommend remediation action."
And here is where the magic starts. The soc-shift-manager kickstarts the incident lifecycle and dynamically hands out micro-tasks to the other specialized sub-agents based on their explicit definitions. As you can see in the terminal output below, the lead orchestrator instantly maps out our high-level request into three distinct, parallel investigation phases (Threat Research, Internal Exposure Analysis, and Remediation Planning):
We can trace the underlying execution as the main agent coordinates the sub-agents, seamlessly tracking individual progress as each cell processes its respective workflow phase. Because these deep analytical tasks run completely in the background to keep your workspace responsive, the interface provides a live, visual tree-view. This lets you monitor exactly which sub-agent is active at any given second-such as extracting KEV (Known Exploited Vulnerabilities) details or hunting for indicators inside your SIEM:
We can watch all the required investigation steps being performed by each agent in real-time. This setup gives the human operator perfect visibility and ultimate control over the autonomous workflow, without getting buried under mountains of raw log data.
Crucially, a Human-in-the-Loop (HITL) safety gate is automatically triggered before any production-impacting action is executed. In this example, the secops-engineer agent is tasked with creating new detection rules, but the approval requirement is not left to the model's discretion. The workflow's guardrails explicitly instruct the agent to request human approval before creating production detections, and the underlying “create_rule” tool is additionally configured with an approval gate through the environment settings (ask policy). As a result, the agent pauses execution and waits for human confirmation before deploying any detections into production.
Once I typed "yes", three YARA-L rules designed using fresh intel retrieved by the researchers were immediately deployed as drafts into Google SecOps.
After all the sub-agents finished their respective assignments, I received a comprehensive, consolidated investigation summary compiled by the main orchestrator. In a production environment, outputs like these could be persisted to shared repositories, case management platforms, or knowledge bases to support auditing, collaboration, and future investigations. Within Google SecOps, for example, findings could be written directly back to the case using tools such as create_case_comment, ensuring they remain available beyond the active investigation session.
A full, multi-staged vulnerability sweep completed in less than 10 minutes—a process that manually used to take hours of grueling pivot searches across different platforms!
3. Multi-agent Architecture: Agent Teams
Claude supports many architectural patterns for multi-agent coordination and for this work, I chose Agent Teams.
While Sub-Agents are top-down, hierarchical workers managed sequentially by a single model, Agent Teams represent a flat, peer-to-peer engineering paradigm. Multiple full Claude Code instances run simultaneously, collaborating dynamically through an inter-agent mailbox protocol and self-claiming tasks from a live, shared TASKS.md board.
Claud Code docs have a full comparison of Subagents vs Agent Teams
To use this experimental Agent Teams feature, you set the global feature toggle:
“export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1”
When I gave the Agent Team this query, I watched them collaborate in real time. Instead of stepping on each other's toes, the team immediately analyzed the problem and divided the tasks among themselves based on their specific roles.
What makes this architecture compelling is its ability to coordinate multiple specialized agents while maintaining clear ownership and task separation:
Dynamic Resource Management - An agent knows exactly when its specific domain expertise is no longer needed. Once its task is complete, it gracefully shifts to an idle state, freeing up system resources and preventing unnecessary noise or overlapping commands.
Human-in-the-Loop (HITL) Guardrails - The team operates within predefined approval boundaries. As illustrated in the previous example, production-impacting actions can be explicitly configured through workflow guardrails and tool-level policies to require human approval. When such actions are encountered, the agents pause execution and wait for authorization before proceeding.
Imagine deploying a team like this during a live, high-severity ransomware incident—where specialized AI units instantly divide tasks, hunt threats in parallel, and automatically pause for your approval before taking critical response actions.
4. The Blueprint: Agent Goals
If Skills define how work gets done, and Sub-Agents define who does the work, Agent Goals define the ultimate what.
Unlike a traditional SOAR playbook that breaks if step 3 of a 15-step sequence fails, an Agent Goal provides a high-level objective and allows the model to utilize its own autonomous reasoning loop (Evaluate ➔ Act ➔ Observe) to figure out the path to success.
By issuing a /goal, you are effectively telling the agent: "I don't care how many Sub-Agents you need to spawn, or how many internal errors you have to self-correct along the way. Do not stop looping until this specific end-state is achieved.
For example, instead of running individual commands to review UDM logs and manually check reputation feeds, you can assign a strict, condition-based goal:
/goal Investigate the user 'elirazo@example.com' over the last 72 hours in Google SecOps. Your success conditions are:
1. Extract any IPs this user logged in from and check their reputation in GTI.
2. Search UDM logs for any lateral movement or excessive file download events tied to this user.
3. If the user is benign, summarize the activity. If malicious, draft a YARA-L rule to detect this specific behavioral chain and pause for my approval.
Do not stop looping until all three conditions are satisfied.
Let's run the /goal command with these exact conditions in our terminal:
Once initiated, we can watch the agent work continuously in the background. Notice how it handles large result sets, inspects JSON structures when they look different than expected, parallelizes its GTI lookups, and actively self-corrects without any human intervention:
After 8 minutes of autonomous execution, the goal in our test completed successfully, returning a highly detailed, structured timeline of the user's activity and a final Benign verdict, correctly noting that the anomalous queries were just the security analyst auditing their own environment.
Where This Shines in SecOps:
In a real-world enterprise SOC, this Goal-oriented architecture is an absolute game-changer for complex incident scoping (mapping the blast radius of a breach) and deep-dive threat hunts. Usually, tracing a potentially compromised identity across multiple days requires an analyst to perform dozens of grueling, manual pivot searches - querying an IP, grabbing a hash, checking a feed, going back to the SIEM. With Agent Goals, you assign the objective, go grab a coffee, and return to a definitive, fully enriched investigation report that is ready for a final human verdict.
FinOps & Reality Check
Seeing these agents collaborate in real-time is undeniably impressive, but bridging the gap between a successful lab demonstration and a resilient, enterprise-grade operation requires addressing two harsh production realities: environment variance and resource consumption.
It is critical to note that the performance benchmarks shown above were captured within a controlled lab environment. In a live production SOC, enterprise network noise, unpredictable log formats, and variable third-party API latencies will inevitably cause execution metrics to fluctuate.
Furthermore, with great autonomy comes a non-trivial API invoice. Running a complex multi-agent framework is fundamentally resource-intensive. Left unchecked, autonomous agents can easily trap themselves in infinite analysis loops or redundant sub-queries, burning through your token budget faster than anticipated. Building a mature agentic SOC requires clear execution boundaries from day one, including cost controls, maximum execution depth, turn limits, and, where appropriate, time-based safeguards. Otherwise, the financial cost of automated execution can quickly outweigh the security value delivered.
If you've read this far, you might be feeling a little overwhelmed. Let's take a look at the following table:
The Coexistence of AI and SOAR
Let's address a common industry anxiety: This architecture does not mean SOAR is dead. Instead, think of AI as the brain and your existing SOAR infrastructure as the muscle. You still want your deterministic, API-driven SOAR playbooks to handle the heavy lifting of disabling corporate accounts, altering firewall rules, or modifying IAM configurations because those actions require absolute precision.
The difference is that a human analyst no longer needs to spend 45 minutes manually correlation-hunting through log groups to decide if that SOAR playbook should be run. The Multi-Agent ecosystem does the analytical engineering in seconds, presenting the human supervisor with a verified verdict and a ready-to-fire response option.
That said, the verdict is a starting point, not gospel: the analyst still validates the underlying intel itself: an autonomously retrieved IOC or TTP is a lead to verify, not ground truth. The human gate is still required.
Why the Community Must Adopt Agentic Architectures: My Top Four
Shifting from basic chat boxes to protocol-driven, multi-agent systems is not just a cool UI upgrade—it is a fundamental requirement for the survival of the modern SOC. Because these principles are standardized via open frameworks like MCP, they are completely model-agnostic; it doesn’t matter if your underlying engine is Claude, Gemini, or any other advanced LLM.
Here are the four biggest reasons why the security community needs to embrace this paradigm right now:
-
Defending at Machine Speed Against AI-Armed Adversaries
The threat landscape has fundamentally changed. Attackers are already using autonomous AI pipelines to rapidly discover vulnerabilities, dynamically adapt evasion techniques, and deploy malware. A SOC relying on manual triage or rigid, hardcoded SOAR logic is operating far behind the adversary's OODA loop (Observe, Orient, Decide, Act). Agentic systems act as an asymmetric equalizer, compressing the time between a zero-day announcement and live detection from hours down to literal seconds.
-
Catching the "Low and Slow" Attacks
Alert fatigue is how major breaches happen. Because human analysts are overwhelmed, SOCs heavily tune their SIEMs to only trigger on high-fidelity, high-threshold events-meaning they often miss the early, quiet signs of an intrusion. Agentic ecosystems don’t suffer from fatigue. They can be deployed to autonomously investigate every single low-severity anomaly - correlating a slightly odd login with a minor file modification 12 hours later, uncovering the subtle campaigns that traditional rules ignore.
-
Dynamic Resilience to Engineering Drift
When a security tool changes an API response payload, updates a JSON schema, or tweaks its UI, hardcoded SOAR automation playbooks break entirely. This leaves the SOC blind until an engineer rewrites the script. A dynamic agentic system powered by MCP doesn't rely on rigid path-matching. Because the LLM understands context, it can natively interpret schema updates, recognize alternative data fields, and dynamically discover new ways to gather the data it needs without human intervention.
-
Democratizing Playbooks as "Policy-as-Code"
Documenting security workflows inside platform-specific implementations can make methodologies harder to review, maintain, and reuse across teams and environments. Writing your SOC methodology inside git-managed, markdown-based frameworks (SKILL.md) ensures your security playbooks are treated as clean Policy-as-Code. They become instantly auditable, peer-reviewed, and completely portable across any AI infrastructure or future model release.
Conclusion
Combining the multi-agent patterns we explored today with the native MCP packages from Google SecOps creates an absolute powerhouse for defensive teams, fundamentally reshaping the daily reality of cyber defense.
Instead of security engineers spending their weeks building and maintaining brittle automations to handle an ever growing list of security use cases, the modern SOC elevates them into Agent Architects. Your focus shifts from writing manual, brittle scripts to orchestrating and tuning specialized autonomous agents that do the heavy lifting behind the scenes.
This is where Google’s MCP integration shines brightest, providing a universal, native linguistic bridge directly into cloud-scale telemetry and Google Threat Intelligence (GTI). Adopting this protocol today ensures your defensive stack is automatically primed for a wave of upcoming innovations, deeper model optimizations, and tighter product integrations
By wrapping our tools in standard protocols like MCP and structuring our LLMs into specialized operational hierarchies, we aren't just giving analysts a faster way to search logs. We are building an elastic, resilient, autonomous security architecture capable of out-thinking and out-pacing the next generation of cyber threats.
