The AI Learning Hub Journal

Walkthrough: Phishing Triage End-to-End

Google SecOps: Phishing Alert Firessuspicious URL · attachment hash · email bodyOrchestrator Agentreceives alert · plans workflow · governs subagentsORCHESTRATOR① INPUT HOOKstrip injection payloads from email body before it enters model contextIOC Enrichment Subagentscope: read-only GTI + VirusTotal · no write access · isolated contextSUBAGENTSKILL: gtl_lookupURL verdict · actor attribution · campaignSKILLCONNECTOR: GTI MCP Serverauth · API translation → Mandiant GTISKILL: vt_scanhash scan · 70+ engine resultsSKILLCONNECTOR: VT MCP Serverauth · API translation → VirusTotalOrchestrator synthesizes findings→ Recommends: Isolate Host② ACTION HOOKpause execution · notify on-call analyst · wait for approval before tool firesAnalyst: APPROVEhost isolation executes③ AUDIT HOOKimmutable trace → Agent Security DashboardSkills define the interface · connectors own the external plumbing · hooks govern the pipeline
Phishing triage walkthrough — each step activates a distinct M3 architectural concept

The Scenario

A phishing alert fires in Google SecOps. The email contains a suspicious URL and an attachment hash. The goal: enrich the indicators, decide whether to isolate the host, and produce an auditable record — without the analyst doing any manual pivoting. This single workflow activates five M3 architectural concepts at once: orchestrator, subagent, skills, connectors, and hooks. Each plays a distinct role — none is interchangeable with another. Follow the diagram step by step to see which concept fires at which moment and why.

Subagent: Scoped by Design

The orchestrator receives the alert and immediately spawns an IOC Enrichment subagent. The key decision is what scope the subagent gets: read-only access to GTI and VirusTotal — nothing else. It cannot write to any system, cannot touch identity management, cannot close the case. This is least-privilege applied to an autonomous system. Why it matters in a sales conversation: if the subagent is compromised via a poisoned email body, the blast radius is bounded by its scope. An attacker who hijacks the subagent gets read-only TI lookups — not the keys to the SOC.

Skills and Connectors: Two Distinct Layers

The subagent calls two skills: gtl_lookup and vt_scan. The agent side of this looks simple — discover the skill by name, call it with the right inputs, receive a structured result. The implementation side involves a connector: the GTI MCP server is the connector that bridges the skill interface to the Mandiant API, handling auth, rate limiting, request formatting, and error translation. The subagent never touches the API directly. This separation matters: skills define what can be called (the interface); connectors define how it reaches the external service (the implementation). In the phishing triage workflow, the GTI and VirusTotal connectors are Google-shipped MCP servers — the customer does not write or maintain them. If a prospect asks "what does it take to add a new tool to your agent stack?" the honest answer runs through this distinction: adding a tool means either consuming an existing connector (MCP server) or building one. The connector question is where "AI-native" platforms separate from legacy SOAR with an AI wrapper.

Hooks: Three Control Points in One Workflow

Three hook types activate during this workflow, each at a different moment. Input hook: before each skill call, the hook strips injection payloads from the retrieved email body — so even if the phishing email contains adversarial instructions embedded in its text, those instructions never reach the model context. This fires silently, without changing the workflow logic. Action hook: when the orchestrator recommends "isolate host," the hook intercepts before the tool call fires. Execution pauses. The on-call analyst receives a notification with the full enrichment context and an approve/deny prompt. Only after approval does the isolation execute. Audit hook: after every step — every skill call, every model decision, every approval click — the hook writes an immutable timestamped entry to Cloud Logging. No agent code manages this; the hook does it automatically across the entire pipeline.

What the Analyst and CISO See

From the analyst perspective: a pre-researched case arrives with the GTI verdict, VirusTotal scan results, and a plain-language recommendation already assembled. The analyst reviews context and clicks approve or deny — the investigation work is done. From the CISO perspective: the Agent Security Dashboard shows the complete trace — which skills were called, what data was retrieved, which hook fired, who approved, and at what timestamp. This is not a summary; it is a full reconstruction of every agent action. The answer to "can you prove what the agent did and why?" is always yes. That auditability is the architectural property that hooks provide — and it is why Agent Gateway (which implements hooks at the infrastructure level) is a governance pitch, not a product pitch.

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.