Skip to content
active security v0.3.1 Security Analyst Investigation Toolkit Created 2026-06-24 · Updated 2026-07-24

SAINT — Security Analyst Investigation Toolkit

  • Product: Security Analyst Investigation Toolkit
  • Family: Security Analyst Toolset

Objective

Equip the cybersecurity team with an AI-powered investigation agent — built on Kiro and connected to security-relevant MCP servers — that can query threat intelligence, search logs, resolve network/IP context, and produce structured investigation artifacts in a shared workspace.

Context

Security analysts today context-switch between multiple web consoles (Google SecOps, VirusTotal, CrowdStrike Falcon, Cloudflare Radar, AWS Security Hub, Infoblox, Nautobot, OpenSearch Dashboards) during investigations. Each tool requires separate authentication, separate query languages, and produces results in different formats. An analyst investigating a suspicious IP must manually copy it between half a dozen tools to build context.

Meanwhile, Engineering has deployed centralized MCP gateways (EMCPG-AWS, EMCPG-Cloudflare) that proxy multiple MCP servers behind a single authenticated endpoint with per-tool RBAC. The Logging Lake already indexes CloudTrail, VPC flow logs, and Cloudflare HTTP logs in OpenSearch, and a per-user-auth OpenSearch MCP server (LOGL) is planned. SIRIWAIT provides a shared git workspace for multi-agent investigation collaboration, and MACP provides a shared memory/entity graph for multi-agent coordination.

SAINT is the missing piece: the agentic harness, skill configuration, investigation playbooks, MCP server registry, gateway portal, and platform integrations that tie these together into a cohesive cybersecurity investigation workflow.

Tools In Use

Agent Platform (Agentic Harness)

  • Kiro — AI agent runtime providing session management, MCP client multiplexing, and context management
  • Harness packaging — TBD: local CLI install, containerized service, or wrapper script that configures Kiro with the SAINT skill and gateway credentials

MCP Servers (Dedicated Security Gateway)

Server Purpose Status
Google SecOps (Chronicle) SIEM search, UDM queries, detection rules, case management, SOAR Official MCP server (includes remote managed option)
Google Threat Intelligence (VirusTotal) IOC lookup (IPs, domains, hashes, URLs), threat reports Official MCP server; deployment detailed in the GTI component plan
CrowdStrike Falcon Endpoint telemetry, detections, host context, identity protection, NGSIEM Official MCP server (falcon-mcp on PyPI)
Cloudflare Radar Internet-wide threat intelligence, DDoS/L7 attack data, BGP hijacks, URL scanning Official MCP server (also via unified mcp.cloudflare.com)
AWS Security Hub / GuardDuty AWS-native security findings, compliance, threat detection Findings accessible via the general AWS API MCP Server; adjacent dedicated servers exist (Security Agent, Well-Architected Security, CloudTrail)

MCP Servers (Via EMCPG — shared)

Server Purpose Status
Infoblox NIOS DNS/DHCP/IPAM context, lease history, network asset intelligence Official MCP server announced (Infoblox IQ; early access, GA fall 2026); community NIOS WAPI servers exist
Nautobot (NetBox-like) Network device inventory, IP assignments, circuit/site context Official MCP server from Network to Code
Logging Lake (OpenSearch) CloudTrail, VPC flow logs, Cloudflare HTTP logs Planned — LOGL plan
GitHub Access SIRIWAIT repos, commit investigation artifacts Available via EMCPG
Slack Coordinate with analysts, post findings to incident channels Available via EMCPG
Datadog Infrastructure metrics, APM traces, error context Available via EMCPG

Infrastructure

  • Dedicated Security Gateway — MCP gateway hosting the security-specific servers (Google SecOps, GTI, Falcon, Radar, AWS Security Hub) with RBAC; scoped to the cybersecurity team
  • EMCPG (Cloudflare variant) — shared MCP gateway hosting Infoblox, Nautobot, Logging Lake, GitHub, Slack, and Datadog; used by both the cybersecurity team and Engineering
  • SIRIWAIT — git-based workspace for investigation artifacts
  • MACP — shared memory for multi-analyst investigations

Scope

In scope

  • Agentic harness — packaged runtime for analysts to run SAINT (Kiro execution environment, MCP client connections, session management, analyst-facing interface)
  • SAINT skill — system prompts, steering files, and behavior definitions that give the agent its security analyst persona
  • Investigation playbooks — encoded workflows for common investigation types (compromised account, suspicious lateral movement, phishing analysis, data exfiltration)
  • Security MCP server registry — adopt official MCP servers for Google SecOps, GTI, CrowdStrike Falcon, Cloudflare Radar, and AWS Security Hub; deploy and register each on the appropriate gateway (security-specific servers on the dedicated security gateway; Infoblox, Nautobot, and Logging Lake on EMCPG)
  • Security gateway portal — stand up a dedicated security gateway for the security-specific servers with RBAC scoping access to the cybersecurity team; shared servers (Infoblox, Nautobot, Logging Lake, GitHub, Slack, Datadog) are reached via EMCPG
  • Platform integrations — SIRIWAIT (structured artifact production), MACP (shared findings/entities), Slack (incident channel alerting)
  • Onboarding documentation — setup guide for cybersecurity analysts to install the harness and connect to the security gateway

Out of scope

  • Building the EMCPG gateway itself (existing project)
  • Building the OpenSearch MCP server (LOGL project)
  • Building SIRIWAIT (existing project)
  • Building MACP (existing project)
  • Automated response actions (blocking, isolation, quarantine) — read-only investigation only in phase 1
  • Replacing the SIEM (Google SecOps remains the SIEM; SAINT queries it, doesn't replace it)

Architecture

graph TD
    subgraph "Analyst Workstation"
        subgraph "Agentic Harness"
            K[Kiro Runtime]
        end
        SK[SAINT Skill + Playbooks]
        SK -.->|loaded into| K
    end

    subgraph "Dedicated Security Gateway"
        SecPortal[Security Gateway Portal<br/>Cloudflare Access + RBAC]
    end

    subgraph "EMCPG-Cloudflare (shared)"
        EMCPGPortal[MCP Server Portal<br/>Cloudflare Access + RBAC]
    end

    subgraph "Security MCP Servers"
        GS[Google SecOps MCP<br/>UDM search, cases, detections, SOAR]
        GTI[Google TI MCP<br/>IOC lookups, threat reports]
        CF[CrowdStrike Falcon MCP<br/>endpoint telemetry, detections, hosts]
        CR[Cloudflare Radar MCP<br/>DDoS, BGP, URL scanning]
        AWS[AWS Security Hub MCP<br/>GuardDuty, Inspector, Config]
    end

    subgraph "Shared MCP Servers (via EMCPG)"
        IB[Infoblox NIOS MCP<br/>DNS/DHCP/IPAM context]
        NB[Nautobot MCP<br/>network inventory]
        LL[Logging Lake MCP<br/>CloudTrail, VPC flow,<br/>Cloudflare HTTP]
        GH[GitHub MCP<br/>SIRIWAIT repos]
        SL[Slack MCP<br/>incident channels]
    end

    subgraph "Collaboration"
        SW[SIRIWAIT<br/>git investigation workspace]
        MC[MACP<br/>shared memory + entities]
    end

    K -->|OAuth| SecPortal
    K -->|OAuth| EMCPGPortal
    SecPortal --> GS
    SecPortal --> GTI
    SecPortal --> CF
    SecPortal --> CR
    SecPortal --> AWS
    EMCPGPortal --> IB
    EMCPGPortal --> NB
    EMCPGPortal --> LL
    EMCPGPortal --> GH
    EMCPGPortal --> SL
    K -->|MCP| MC
    K -->|git via GitHub MCP| SW

Investigation Playbooks

The SAINT skill encodes investigation workflows that guide Kiro through structured analysis. Each playbook is a sequence of MCP tool calls with conditional logic based on results.

Example: Suspicious IP Investigation

  1. Enrich — GTI lookup (reputation, associated malware, passive DNS), Infoblox (internal vs external, DHCP lease history), Nautobot (which network/site if internal)
  2. Search — Logging Lake (VPC flow logs for connections to/from IP, CloudTrail for API calls from IP, Cloudflare HTTP for web requests)
  3. Correlate — Google SecOps (UDM search for the IP across all log sources, check existing detections/cases)
  4. Document — Post findings + entities to MACP, commit IOC report to SIRIWAIT
  5. Alert — Post summary to Slack incident channel

Example: Compromised Account Investigation

  1. Scope — Google SecOps (UDM search for all activity by the user), CloudTrail (API calls, console logins, assumed roles)
  2. Timeline — Reconstruct sequence of events from multiple sources
  3. Lateral movement — VPC flow logs from the user's source IPs, new role assumptions, unusual service usage
  4. Persistence — CloudTrail search for IAM key creation, policy changes, new resources
  5. Document — Timeline markdown + entity graph to SIRIWAIT and MACP

Components

SAINT is composed of six distinct components, each with its own delivery artifact and dependency chain.

Component What it is Delivered as
Agentic Harness Runtime that hosts the SAINT agent — Kiro execution, MCP client connections, session management, analyst-facing interface Kiro CLI / deployment config / wrapper service
SAINT Skill Agent persona — system prompts, steering files, investigation behavior definitions Kiro steering files / AGENTS.md in a git repo
Investigation Playbooks Multi-step workflows (suspicious IP, compromised account, etc.) that chain MCP tool calls with conditional logic Skill files or playbook library repo
Security MCP Server Registry Vendor MCP servers deployed and ready to serve — security-specific (Google SecOps, GTI, Falcon, Radar, AWS Security Hub) plus shared (Infoblox, Nautobot, Logging Lake) reached via EMCPG Deployment manifests / container configs
Security Gateway Portal Dedicated security gateway with RBAC scoping the security-specific servers to the cybersecurity team Dedicated gateway infrastructure (Cloudflare Access policies)
Platform Integrations Wiring to SIRIWAIT (artifact output), MACP (shared memory), Slack (alerting) Configuration within skill + gateway

Phasing

Phase 1 — Core Integration (MVP)

Security MCP Server Registry: - Adopt official Google TI (VirusTotal) MCP server from google/mcp-security - Adopt official CrowdStrike Falcon MCP server (falcon-mcp) - Adopt official Infoblox MCP server (early access) or community NIOS WAPI server - Adopt official Nautobot MCP server (Network to Code)

Security Gateway Portal: - Stand up the dedicated security gateway and register GTI and Falcon on it with RBAC for the cybersecurity team - Register Infoblox and Nautobot on EMCPG (shared)

SAINT Skill: - Create Kiro SAINT skill with security analyst persona and basic investigation prompts

Agentic Harness: - Package and document the analyst setup (Kiro install + gateway credentials + skill activation)

Investigation Playbooks: - Suspicious IP investigation (enrich from GTI, Infoblox, Nautobot)

Validation: - End-to-end: analyst asks about a suspicious IP, gets enriched context from all sources

Phase 2 — SIEM + Log Integration

Security MCP Server Registry: - Adopt official Google SecOps MCP server from google/mcp-security (UDM search, detections, cases, SOAR) - Integrate Cloudflare Radar MCP for internet-wide threat context - Integrate AWS Security Hub / GuardDuty findings via the general AWS API MCP Server (or adjacent Security Agent / Well-Architected Security servers) - Integrate with Logging Lake MCP (depends on LOGL completion)

Investigation Playbooks: - Connect investigation playbooks that span SIEM + log lake (enrich → search → correlate → document) - Compromised account investigation playbook

Phase 3 — Collaboration Integration

Platform Integrations: - Integrate SIRIWAIT (artifact production workflows) - Integrate MACP (entity graph, shared findings)

Agentic Harness: - Multi-analyst investigation: two analysts with their own harness instances collaborating on one incident via shared MACP/SIRIWAIT

Phase 4 — Advanced

  • Automated playbook triggering from Google SecOps detection alerts
  • Investigation templates that bootstrap a new SIRIWAIT repo + MACP room from a PagerDuty incident
  • Cross-platform correlation (Falcon endpoint events → SecOps UDM → Logging Lake network flows)

Future Ideas

  • Arista NDR (Awake Security) — network detection and response telemetry, threat hunting, lateral movement detection. No MCP server exists; would require custom build wrapping their API.
  • Palo Alto Cortex XDR — extended detection and response across endpoint/network/cloud
  • ServiceNow SecOps — security incident ticketing and workflow integration

MCP Server Build Decisions

Google SecOps (Chronicle)

Google provides an official MCP server for Security Operations, including a fully managed remote server option. The server covers UDM search, detection rules, cases, entity context, and SOAR integrations.

Recommendation: Adopt the official Google MCP Security server. Evaluate whether the remote managed option or the self-hosted version fits the gateway architecture better.

Infoblox NIOS

Infoblox announced an official MCP server in June 2026 as part of the Infoblox IQ platform. It covers both NIOS (on-prem) and Universal DDI, exposing DNS, DHCP, IPAM, and security intelligence via MCP. Currently in early access; GA planned for fall 2026. Community MCP servers wrapping the NIOS WAPI REST API also exist.

Recommendation: Request early access to the official Infoblox MCP server. If timeline doesn't align with Phase 1, adopt a community NIOS WAPI MCP server or build a thin wrapper — the WAPI surface needed is small (DNS record lookup, DHCP lease history, IP/subnet context).

Google Threat Intelligence (VirusTotal)

Google provides an official MCP server that includes GTI capabilities — IOC lookups, malware analysis, threat reports, and threat actor profiles. Part of the same google/mcp-security project as the SecOps server.

Recommendation: Adopt the official Google MCP Security GTI server. Premium GTI features require a paid Google Threat Intelligence subscription.

Nautobot

An official MCP server exists from Network to Code (the Nautobot maintainers). Requires Nautobot 2.x and Python 3.11+.

Recommendation: Adopt. Evaluate coverage against our needs (device lookup, IP/prefix context, site/circuit info).

Risks

Risk Likelihood Impact Mitigation
Google SecOps API rate limits constrain agent queries Medium Medium Implement caching in the MCP server; design queries to be specific rather than broad
Vendor abandons or breaks an official security MCP server Low Medium All security MCP servers are vendor-maintained (Google, CrowdStrike, Cloudflare, AWS, Infoblox), so the surface is small; pin server versions, and fall back to a thin API wrapper if a server is dropped
Analyst adoption — cybersecurity team unfamiliar with Kiro High Medium Hands-on workshops; pair investigations; start with one willing analyst as champion
Google SecOps may not support per-user OAuth, forcing service-account impersonation Medium Low Use domain-wide delegation to preserve per-user audit trail; acceptable under the OAuth-preferred policy since SecOps access is read-heavy
LOGL (OpenSearch MCP) delivery delays Medium Medium Phase 2 dependency; phase 1 is viable without it using direct OpenSearch API wrappers
Infoblox official MCP server not GA until fall 2026 Medium Low Use community NIOS WAPI MCP server as fallback; WAPI surface is well-documented and stable
Too many tools overwhelm the agent context Low Medium Start with core tools per playbook; add progressively; use Kiro skill files to scope which tools are relevant per investigation type
Bring-your-own harness exposes the gateway to uncontrolled clients Medium Medium An unauthorized or poorly configured harness could misuse gateway tools, exfiltrate data, or produce misleading artifacts. Enforcement may not be technically possible: if the gateway authenticates the user via OAuth regardless of client, there is no mechanism to restrict which harness connects. Mitigation options where feasible: API key scoping, client attestation, usage auditing. Otherwise accept as a known limitation and rely on audit trail plus policy.

Success Criteria

  • An analyst can install the harness and connect to the security gateway in under 30 minutes using the onboarding guide
  • An analyst can ask Kiro "investigate this IP" and receive enriched context from GTI, Infoblox, and Nautobot without leaving the terminal (Logging Lake correlation added in Phase 2)
  • Investigation results are posted to MACP so other analysts' agents can discover them
  • A complete suspicious-IP investigation (enrich → search → correlate → document) takes <5 minutes, measured against a manual baseline timed on real investigations before rollout (working assumption ~30 minutes, unverified)
  • Security MCP servers are behind RBAC — only the cybersecurity team has access
  • At least 3 analysts regularly using SAINT for real investigations within 60 days of deployment

Open Questions

  • Is the dedicated security gateway scoped to the cybersecurity team as a whole, or does it carry per-server RBAC so Engineering can reach lower-sensitivity servers (e.g. GTI) while endpoint and case data stay cybersecurity-only? Engineering access is expected but not yet decided; the GTI component plan currently targets both audiences.
  • Does the Google SecOps MCP server support per-user OAuth, or will it require domain-wide delegation / service-account impersonation to satisfy the OAuth-preferred policy?
  • Does the official Nautobot MCP server (Network to Code) support our Nautobot version and expose the tools we need (device lookup, IP/prefix context, site/circuit info)?
  • What's the right agent prompt length/context budget? Security investigations can produce large amounts of data — how does the agent summarize effectively?
  • Should the SAINT skill be a Kiro steering file (~/.kiro/steering/) or a project-level AGENTS.md in a dedicated repo?
  • Harness: delivery format — will the harness be delivered as a local IDE/CLI on analyst workstations, Kiro Web, or a custom interface? This affects UX, session persistence, and analyst workflow but not the backend architecture.
  • Harness: bring-your-own policy — the Security Gateway Portal component may be usable by a bring-your-own harness (not just the SAINT-provided one). This is TBD and carries risk (see Risks table). May also be moot if not enforceable.
  • Harness: session persistence — if an investigation spans hours or days, does the harness preserve session state, or does the analyst restart from scratch?
  • Harness: deployment ownership — who ships and maintains the harness? Is it just "install Kiro" plus a config repo, or is there a wrapper (systemd unit, Docker image, internal CLI) that the team owns?

References

Decisions

Date Decision Rationale
2026-07-06 Split MCP servers across two gateways: a dedicated security gateway for security-specific servers (Google SecOps, GTI, Falcon, Radar, AWS Security Hub) and EMCPG for shared servers (Infoblox, Nautobot, Logging Lake, GitHub, Slack, Datadog) Stronger isolation for sensitive security tooling while reusing existing shared infrastructure for common tools; the harness connects to both
2026-07-06 Prefer per-user OAuth for all MCP server authentication; shared credentials allowable only for read-only access where OAuth is unavailable Preserves per-analyst audit trail; limits blast radius of shared credentials to read-only operations
2026-07-06 Gateway is multi-tenant shared infrastructure; each analyst gets their own harness instance and authenticated session No shared agent process needed; gateway handles concurrent access; simpler architecture
2026-07-06 Gateway is location-agnostic — any authenticated client can reach it regardless of where the harness runs Backend architecture does not depend on harness delivery format; decouples infrastructure decisions from UX decisions
2026-06-25 Adopt official vendor MCP servers over custom builds where they exist (Google SecOps/GTI, CrowdStrike Falcon, Cloudflare Radar, Nautobot, Infoblox) Vendor-maintained servers reduce maintenance burden and dependency surface; only thin custom wrappers needed where no server exists
2026-06-25 Read-only investigation only in phase 1 (no automated response actions) Limits blast radius while the agent workflow is validated; response automation deferred to a later phase

Changelog

Date Status Change
2026-06-24 draft Initial draft
2026-06-25 draft Updated MCP server availability: Google SecOps, GTI, CrowdStrike Falcon, Cloudflare Radar, and AWS Security Hub all have official servers; removed Under Evaluation section; updated phasing and references
2026-06-25 draft Validation pass: corrected Infoblox MCP link, accurately scoped AWS Security Hub/GuardDuty access, fixed Phase-1 success criterion, refreshed stale Nautobot open question, added Nautobot adopt bullet, updated Context console list, populated Decisions table
2026-07-06 active Reconciled with product map (saint registered, product_type Pending): promoted status draft → active, bumped version 0.2.0 → 0.3.0. Added Components section decomposing SAINT into six deliverables (Agentic Harness, SAINT Skill, Investigation Playbooks, Security MCP Server Registry, Security Gateway Portal, Platform Integrations); aligned Scope, Architecture, Phasing, and Success Criteria to reference components consistently. Resolved SOC questions (Chris Kurtz): recorded two-gateway topology (dedicated security gateway + EMCPG for shared tools), multi-tenant/per-user session model, location-agnostic gateway, and OAuth-preferred auth policy as decisions; redrew architecture diagram; re-sorted MCP server tables by gateway; added bring-your-own-harness risks; refined harness open questions
2026-07-24 active Review pass: rewrote the inverted upstream-maintenance risk as a vendor-abandonment risk with a real mitigation; merged two duplicate bring-your-own-harness rows into one; made the investigation-time criterion measurable by flagging the ~30-minute manual baseline as an unverified assumption to be timed; cross-linked the GTI component plan from the server registry and References; added an open question on whether the security gateway carries per-server RBAC or a blanket cybersecurity scope