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

Google Threat Intelligence MCP Server — Enterprise Deployment via the SAINT Security Gateway

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

Objective

Deploy Google's Threat Intelligence (GTI/VirusTotal) MCP server on ECS Fargate behind the dedicated security gateway, giving all engineers and cybersecurity analysts agentic access to IOC lookups, malware analysis, threat actor research, and vulnerability intelligence — without individual API key management.

Context

Google's mcp-security project provides MCP servers for Google's security products. The GTI server wraps the VirusTotal Enterprise API via a Python FastMCP server (gti-mcp package, Apache 2.0), exposing:

  • IOC lookups — file hashes, domains, IPs, URLs with reputation scoring
  • Threat actor research — APT group profiles, campaigns, TTPs
  • Malware family analysis — sandbox behaviors, network indicators, execution chains
  • Vulnerability search — CVE details with exploitation context

There is no Google-managed remote MCP endpoint for GTI — only SecOps/Chronicle has one (chronicle.googleapis.com/mcp). GTI must be self-hosted.

Today, anyone wanting this capability must obtain their own VirusTotal API key and configure the MCP server locally. By deploying GTI on Fargate behind the dedicated security gateway, a single organizational Enterprise API key is held server-side. Users authenticate to the portal via corporate SSO; the portal proxies requests to the GTI endpoint with the shared credential injected at the container level.

Relationship to Other Plans

  • SAINT — this plan delivers one entry in SAINT's Security MCP Server Registry; the dedicated security gateway it registers on is SAINT Phase 1 work, so this deployment is blocked until that gateway exists
  • SIRIWAIT — security analysts using GTI during incident investigations is a primary use case
  • AVATAR — vulnerability intelligence from GTI complements AVATAR's automated assessment
  • EMCPG (ddt-engineering-mcp-gateway-cloudflare) — not used by this plan; per SAINT's 2026-07-06 topology decision, security-specific servers live on the dedicated security gateway while EMCPG carries shared servers (Infoblox, Nautobot, Logging Lake, GitHub, Slack, Datadog)

Tools In Use

  • Dedicated Security Gateway — Cloudflare MCP portal for security-specific servers (auth, portal, access policies); SAINT Phase 1 deliverable, not yet built
  • Google MCP Security (google/mcp-security, gti-mcp v0.1.2) — upstream GTI MCP server
  • ECS Fargate — container hosting (ops-sandbox, 487053949292)
  • ECR — container image registry
  • AWS Secrets Manager — VirusTotal API key (synced from Vault)
  • Cloudflare Tunnel — private connectivity from the portal to the Fargate task
  • OpenTofu — infrastructure deployment

Architecture

graph LR
    subgraph Developers & Analysts
        D1[Kiro / AI Agent]
        D2[Claude / AI Agent]
    end

    subgraph Cloudflare
        IDP[Corporate IdP via SSO]
        Portal[Security Gateway Portal<br/>Access policies<br/>Managed OAuth]
        Tunnel[Cloudflare Tunnel<br/>cloudflared sidecar]
    end

    subgraph AWS -- ops-sandbox
        ECR[ECR Repository<br/>gti-mcp image]
        ECS[ECS Fargate Task<br/>gti-mcp container<br/>+ cloudflared sidecar]
        SM[Secrets Manager<br/>VT_APIKEY]
    end

    subgraph External
        VT[VirusTotal Enterprise API]
    end

    D1 & D2 -->|OAuth/PKCE| Portal
    Portal -->|Authenticate| IDP
    Portal -->|Tunnel| Tunnel
    Tunnel --- ECS
    ECS -->|Bearer VT_APIKEY| VT
    SM -.->|injected at launch| ECS
    ECR -.->|image pull| ECS

Deployment Design

Container Image

FastMCP natively supports Streamable HTTP transport. The container is minimal:

FROM python:3.12-slim
RUN pip install --no-cache-dir gti-mcp==0.1.2
ENV STATELESS=1
EXPOSE 8000
CMD ["gti_mcp", "--transport", "streamable-http", "--host", "0.0.0.0", "--port", "8000"]
  • Pinned to release 0.1.2 for reproducibility
  • STATELESS=1 — no session tracking; each request is independent
  • Exposes /mcp endpoint on port 8000

ECS Fargate Task

Component Detail
Account ops-sandbox (487053949292)
Launch type Fargate
CPU / Memory 256 / 512 (I/O-bound on VT API calls)
Platform version LATEST
Containers gti-mcp (main) + cloudflared (sidecar)
Networking awsvpc, private subnets, no public IP
Service Desired count: 1
Health check TBD

Connectivity: Cloudflare Tunnel

The task runs a cloudflared sidecar that establishes an outbound tunnel to Cloudflare's edge. The portal reaches the GTI server via a private hostname routed through the tunnel. No public endpoint, no ALB, no inbound security group rules.

  • Tunnel created via Terraform (cloudflare_zero_trust_tunnel_cloudflared)
  • cloudflared sidecar connects using a token from Secrets Manager
  • Ingress rule: hostname → http://localhost:8000

Portal Registration

Registered on the dedicated security gateway (repo TBD — created as part of SAINT Phase 1). Illustrative resource:

resource "cloudflare_zero_trust_access_ai_controls_mcp_server" "gti" {
  account_id  = data.cloudflare_account.this.id
  id          = "gti-mcp-${var.environment}"
  name        = "Google Threat Intelligence"
  hostname    = "https://gti-mcp-${var.environment}.${var.dns_zone_name}/mcp"
  auth_type   = "unauthenticated"
  description = "Google Threat Intelligence (VirusTotal Enterprise). Shared read-only API key held server-side."

  is_shared_oauth_callback_enabled = false
  updated_prompts = []
  updated_tools   = []
}

auth_type = "unauthenticated" because the portal handles user auth; the upstream GTI server has no auth layer.

Access Control

Portal access policies (final scope pending — see Open Questions): - ET Engineering (existing, from ewp-cloudflare-teams) - ET Engineering Exception (existing) - ET Cybersecurity (new — to be created in ewp-cloudflare-teams)

Secrets

Secret Source Destination
VT_APIKEY Vault (secret/services/dco/jenkins/ddt/emcpg/{env}/gti) Secrets Manager → ECS task env var
Tunnel token Vault Secrets Manager → cloudflared sidecar env var

Scope

In scope

  • Dockerfile for gti-mcp (Streamable HTTP transport, stateless)
  • ECR repository + CI to build/push image
  • ECS Fargate service (task definition, service, security groups, IAM)
  • Cloudflare Tunnel for private connectivity
  • Portal server registration on the dedicated security gateway (depends on SAINT Phase 1)
  • Access policy definition for the security gateway (see Open Questions on group scope)
  • Vault → Secrets Manager pipeline for VT_APIKEY and tunnel token
  • Standalone repo for container + ECS infra (product ownership TBD)
  • Onboarding documentation update

Out of scope (future phases)

  • SecOps/SOAR/SCC MCP servers — add once GTI proves the pattern
  • Write operations — read-only API key; no file submissions
  • Auto-scaling — start with 1 task; add target-tracking later if needed
  • AWS AgentCore Gateway integration — Cloudflare portal first
  • Custom tool filtering — defer updated_tools unless write tools surface
  • Production account deployment — ops-sandbox for now

Risks

Risk Likelihood Impact Mitigation
Dedicated security gateway not yet built (SAINT Phase 1 dependency) High Medium Sequence portal registration after gateway standup; the gateway-independent work (container image, ECR, Fargate service, tunnel, secrets pipeline) can proceed in parallel so only registration is blocked
Upstream gti-mcp breaking changes Low Medium Pin to v0.1.2; update on our schedule; rebuild is the only change needed
Tunnel connectivity interruption Low Medium cloudflared auto-reconnects; ECS restarts unhealthy tasks
VT API key leak via container logs Low High Never log the key; Secrets Manager injection only; no plaintext in task def
Fargate cold start on fresh deploy Low Low ~5s image pull; tasks stay warm at desired_count ≥ 1

Success Criteria

  • Engineers and analysts query VirusTotal IOCs, threat actors, and vulnerabilities through their MCP client without local API key configuration
  • Portal access restricted to ET Engineering + ET Cybersecurity
  • Single shared Enterprise API key held server-side; zero VT keys in developer environments
  • Request volume observable via Cloudflare Logpush
  • End-to-end latency (portal → tunnel → Fargate → VT API) < 5s p95

Open Questions

  • Access scope: SAINT currently scopes the whole security gateway to the cybersecurity team, while this plan targets engineers and analysts. Does the gateway carry per-server RBAC so ET Engineering can reach GTI while higher-sensitivity servers stay cybersecurity-only? Engineering access is expected but not yet decided.
  • Repo naming convention for the container + ECS infra (e.g., secant-gti-mcp-server, secant-saint-gti, or other)
  • Health check strategy (405 on GET /mcp, custom /health endpoint, or TCP)

References

Decisions

Date Decision Rationale
2026-07-24 GTI is a component of SAINT, not a component of EMCPG The server is security-analyst tooling; SAINT owns the security MCP server registry it belongs to
2026-07-24 Deploy behind the dedicated security gateway; no interim EMCPG deployment Aligns with SAINT's 2026-07-06 two-gateway topology decision; GTI ships when the gateway is ready rather than migrating later

Changelog

Date Status Change
2026-06-24 draft Initial draft
2026-07-24 planned Status active → planned: blocked on the dedicated security gateway, which is SAINT Phase 1 work
2026-07-24 planned Review pass: reassigned parent product from EMCPG to SAINT; retargeted deployment from the EMCPG Cloudflare portal to the dedicated security gateway per SAINT's 2026-07-06 topology decision, with no interim EMCPG deployment; added a risk for the Phase 1 gateway dependency; renamed UTO Engineering to ET Engineering following the org rename; removed the answered product-ownership question; added an open question on per-server RBAC vs. whole-gateway scope; recorded two decisions