MCP Dev Summit BLR 2026 — Operation CipherFall

Disclaimer: ExamplePay is a completely fictitious company name used purely for demonstration purposes in this NightWatch Workshop. Any resemblance to real companies, products, or services is entirely coincidental.

Bridging MCP and ADK for Autonomous Cross-Cloud Site Reliability Engineer (SRE) Operations

Workshop Track: MCP Dev Summit, Bengaluru 2026

Duration: 1 hour

Format: Jupyter Notebooks (hands-on, audience runs along)

---

NightWatch Workshop - The Story

ExamplePay is a Business-to-Business (B2B) payments infrastructure company processing settlement batches across India and Southeast Asia. At 02:10 AM IST, a faulty Infrastructure-as-Code (Terraform) deployment accidentally exposes an internal monitoring port to the public internet. This triggers a subtle but critical chain of events:

The Attack Chain

1. Initial Access (Ingress): ExamplePay’s core payment application runs on Google Kubernetes Engine (GKE) alongside a helper container (batch-export-sidecar) tasked with temporarily storing and archiving settlement files. For observability, this sidecar exposes a Spring Boot Actuator management dashboard on port 8080. The faulty Terraform deployment accidentally applies an allow-all-8080 firewall rule to the production environment, exposing this sidecar to the internet. The attacker discovers the open port and exploits an unpatched public vulnerability (CVE) (e.g., Spring4Shell) in the Actuator dashboard to gain Remote Code Execution (RCE) inside the sidecar container.
2. Command and Control (Egress): Because the VPC relies on GCP’s implied “default allow” egress rule instead of a strict zero-trust deny list, the attacker successfully establishes a reverse-shell connection back to their external Command and Control (C2) server (198.51.100.42).
3. Privilege Escalation: Now operating inside the perimeter, the attacker hijacks the GKE Workload Identity attached to the Pod (svc-batch-export). Due to a common IAM misconfiguration, this Service Account has been granted an overly permissive role (e.g., roles/editor). This excessive permission allows the attacker to mint a new JSON persistence key for themselves to ensure continued access even if the container is restarted.
4. Data Exfiltration: Using the compromised identity, the attacker executes gcloud storage cp to siphon local settlement batch files from the container’s storage volume out to an unregistered external GCS Bucket.

The Detection Gap

To avoid detection, the attacker explicitly throttles the exfiltration speed within their scripts. By keeping the egress byte rate deliberately below deterministic volume-based pager thresholds (“low and slow”), standard alerting rules fail to fire. With no explicit security alerts triggered to wake the on-call Site Reliability Engineer (SRE), the human team remains completely unaware of the active breach.

The Agentic Solution

The Agentic Site Reliability Engineer (SRE) control plane — built on MCP as the protocol spine and Google ADK with Skills-based worker agents — must use continuous semantic anomaly detection to autonomously identify the subtle exfiltration patterns, triage the incident, and remediate the breach (by severing the C2 connection and revoking the IAM key) before the 04:00 AM settlement window opens.

This unfolding crisis forms the backdrop for Operation CipherFall.

---

Key Concepts Demonstrated

TL;DR — What is O(N) → O(1) Protocol Abstraction? Before the introduction of MCP, integrating an AI Agent with N different backend tools (e.g., GCP Logging, AWS CloudWatch, Datadog) required developers to hardcode N proprietary SDK dependencies into the Agent’s codebase. As the number of supported tools grew, the Agent’s dependency bloat grew linearly: O(N).

By introducing the Model Context Protocol (MCP), those proprietary APIs are pushed out into standalone MCP Servers. The AI Agent now only needs to import exactly one dependency: an MCP Client. Regardless of how many hundreds of backend tools are added to the ecosystem, the Agent’s codebase interface is locked at a constant complexity: an O(1) protocol interface.

---

Workshop Structure

workshop/
├── 00_architecture_overview.md          ← MCP + ADK + Skills topology diagrams
├── skills/
│   ├── anomaly-detection-skill/         ← Argus (MonitoringAgent)
│   ├── iam-remediation-skill/           ← Mender (RemediationAgent)
│   └── incident-reporting-skill/        ← Chronicle (ReportingAgent)
├── 01_mcp_server_and_observability.ipynb
├── 02_resource_abstraction_interceptor.ipynb
├── 03_adk_skills_multi_agent.ipynb
├── 04_cipherfall_remediation.ipynb
└── 05_live_gcp_environment.ipynb

---

Architecture

Educational Note on obs://: References to obs:// URIs are present throughout this repository. This is a fictitious, custom protocol created specifically for educational purposes to demonstrate the capability of the Model Context Protocol (MCP) to define domain-specific resource namespaces. In production deployments, these resources act as proxies wrapping actual SDK or API calls to backend telemetry platforms (e.g., Datadog, Splunk, Google Cloud Logging).

Agent  ──MCP(SSE)──▶  examplepay-sre FastMCP server
                            │
                ┌───────────┴───────────┐
                ▼                       ▼
         examplepay-prod         examplepay-staging
         (GCP Project A)           (GCP Project B)
         firewall-rules            firewall-rules
         compute-metadata          compute-metadata

Architectural Components

1. MCP (Model Context Protocol): A standardized, open protocol that enables Large Language Models (LLMs) to securely read from and mutate external infrastructure.
2. SSE (Server-Sent Events): The designated transport layer utilized in this architecture. The FastMCP server binds to an HTTP endpoint (/sse) and uses Server-Sent Events to stream continuous, real-time telemetry updates to the agent without requiring persistent bidirectional WebSockets.
3. Abstraction Layer: The FastMCP server operates as a middleware translation layer. Because the orchestrating agent communicates exclusively via MCP, extending the framework to support an additional cloud environment (or migrating away from GCP) only requires the implementation of new MCP tools on the server. The agent’s core reasoning logic and codebase remain entirely unaltered.

---

Google Cloud Platform (GCP) Projects Simulated

All Google Cloud Platform (GCP) interactions are mocked via JSON fixtures — no real credentials required to run the NightWatch Workshop, except Notebook 05.

Mock Fixtures vs. Real-World GCP

It is critical for attendees to understand that the JSON files in the fixtures/ directory do not mirror the raw schema of GCP APIs. They are simplified abstractions (“Mock State Databases”) designed to fit within a 15-minute hands-on window.

• IAM and Service Accounts (iam_policy_*.json): Squashes GCP Resource Manager bindings, Service Account lists, and Key metadata into a single flat file. In reality, retrieving this requires recursive pagination across three different GCP IAM APIs, plus handling ETag concurrency for mutations.
• Firewalls and VPC Egress (*_firewall.json, vpc_egress_*.json): Condenses complex Compute Engine routing rules and VPC Service Controls (VPC-SC) into simple ingress/egress arrays. In a real GCP environment, these involve deeply nested match conditions and hierarchical organization policies.
• Observability (logs_*, metrics_*, traces_*): Represents structured Cloud Logging, PromQL metrics, and Cloud Trace spans as static JSON arrays. In reality, these are queried dynamically via Google Cloud Logging syntax and PromQL/MQL against massive streaming datasets.

Who handles the API complexity in production? In a real-world scenario, the AI Agent does not write code to handle GCP API recursion or pagination. Instead, developers build a standalone GCP MCP Server that absorbs all of the cloud-specific API complexity.

This architectural pattern practically illustrates the O(N) to O(1) abstraction. While the cloud-specific API logic must still be implemented within the MCP Server, the proprietary SDKs are completely decoupled from the Agent itself. As a result, the Agent’s codebase replaces O(N) proprietary dependencies (such as boto3, google-cloud-logging, or azure-mgmt) with an O(1) protocol interface: the standardized MCP Client.

By deliberately utilizing static fixtures rather than forcing attendees to write boilerplate GCP pagination logic inside the workshop MCP Servers, the curriculum empowers developers to focus purely on the core learning objectives: building the MCP framework and orchestrating multi-agent reasoning loops.

---

📊 Presentation Deck

The official presentation slides utilized during the workshop are available for download and review here: MCP_Summit_BLR_2026_Bridging_Agent_Orchestrators_and_MCP_for_Autonomous_Cross_Cloud_Operations.pdf

---

📚 Comprehensive Documentation Guides

Three specialized guides are provided to ensure maximum readability, clarity, and conciseness:

1. [Usage Guide](file:///usr/local/google/home/anmolsachdeva/mcp-dev-summit-blr-2026/USAGE_GUIDE.md): Contains operational instructions to bootstrap the environment, execute the NightWatch Workshop, and utilize the standalone modules.
2. [Self-Follow Guide](file:///usr/local/google/home/anmolsachdeva/mcp-dev-summit-blr-2026/SELF_FOLLOW_GUIDE.md): Contains conceptual checkpoints, troubleshooting steps, and architectural flows (represented using Mermaid diagrams) structured for independent learners.
3. [Developer Guide](file:///usr/local/google/home/anmolsachdeva/mcp-dev-summit-blr-2026/DEVELOPER_GUIDE.md): Covers architectural boundaries, extension guidelines, and details about open-source alternatives for robust deployments.

Setup

Prerequisites

1. Cloud Requirements (For Notebook 05 Only)

While Notebooks 01–04 use mock fixtures and do not require external credentials, 05_live_gcp_environment.ipynb executes live against Google Cloud Platform (GCP).

• An active Google Cloud Platform (GCP) Account.
• The Google Cloud Command Line Interface (CLI) (gcloud) installed and authenticated (gcloud auth login).
• A sandbox or dedicated Google Cloud Platform (GCP) Project where permissions exist to view Identity and Access Management (IAM) policies and Compute instance metadata.

2. Recommended Background Knowledge

To maximize the value of this 1-hour workshop, attendees should ideally have a foundational understanding of:

• Python & Jupyter: Basic ability to read Python code and execute cells in a Jupyter Notebook.
• Cloud Infrastructure: High-level familiarity with concepts like Identity and Access Management (IAM) (Service Accounts/Roles), Virtual Private Clouds (VPCs), and Firewalls.
• Generative AI: Basic awareness of how Large Language Models (LLMs) and Autonomous Agents function.

Option A: Local Environment

This execution path requires:

• Git
• Python 3.11+
• A virtual environment tool (e.g., venv)

Clone the repository and install the required dependencies. It is highly recommended to use a Python virtual environment to avoid dependency conflicts.

For Linux and macOS:

git clone https://github.com/g-greatdevaks/mcp-dev-summit-blr-2026
cd mcp-dev-summit-blr-2026
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
jupyter notebook workshop/01_mcp_server_and_observability.ipynb

For Windows (Command Prompt or PowerShell):

git clone https://github.com/g-greatdevaks/mcp-dev-summit-blr-2026
cd mcp-dev-summit-blr-2026
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt
jupyter notebook workshop/01_mcp_server_and_observability.ipynb

All 5 notebooks are executed within the same Jupyter kernel. The MCP server initiated in Notebook 01 is shared across all subsequent notebooks.

Option B: DevContainer (Recommended)

The repository includes a fully configured DevContainer for an isolated, reproducible environment. This execution path requires:

• Docker
• An Integrated Development Environment (IDE) such as Visual Studio Code
• The Dev Containers extension

1. Clone the repository and open the folder in Visual Studio Code.
2. When prompted in the bottom right, click Reopen in Container (or press F1 and select Dev Containers: Reopen in Container).
3. The container will build automatically with all dependencies installed. Once loaded, open workshop/01_mcp_server_and_observability.ipynb to begin.

---

[!WARNING] Strict Dependency Pinning This repository enforces strict version pins for fastmcp==3.4.2, pydantic==2.13.4, and pydantic-settings==2.13.1 in the requirements. Do not upgrade or alter these three specific packages, as alternative combinations have known runtime incompatibilities with the current Model Context Protocol specification.

---

Agent Roster

---

MCP Interceptor Pipeline

Every tool call is routed through 5 protocol-layer guards prior to reaching a handler:

1. RateLimitGuard — sliding window, 30 calls/60s per agent
2. AuthScopeGuard — JSON Web Token (JWT) validation + read:sre / write:sre enforcement
3. PayloadSanitizer — Card Number, Email ID, API key, JSON Web Token (JWT) redaction in arguments + responses
4. ToolBoundaryGuard — hard allowlist, blocks phantom tool injection
5. AuditLogger — structured audit entry per call (timestamp, agent, tool, status, and latency)

---

License

Apache License 2.0

---

🎙️ Speakers

Anmol Krishan Sachdeva

• Title: Sr. Solutions Engineer (Platform Engineering), Google
• LinkedIn: @greatdevaks
• Twitter: @greatdevaks
• Sessionize: sessionize.com/greatdevaks

Indumathy Thiagarajan

• Title: Principal Engineer, Wells Fargo
• LinkedIn: @indumathy-thiagarajan

Paras Mamgain

• Title: Technical Lead Manager, Google
• LinkedIn: @parasmamgain
• Twitter: @mamgainparas
• Sessionize: sessionize.com/parasmamgain

---

🛡️ Disclaimer

• The content and views presented during this session are the authors’ own and not of any organizations they are associated with or employed at.
• The code shown in this repository is for illustration and educational purposes only.
  • It is not production-grade; aspects like error handling, security, and scalability are not fully addressed.