MCP Dev Summit Mumbai 2026

We All have been building AI Agents with MCP since it launched in 2024, but there's one thing no one is talking about - "What happens when MCP Fails? (and they fail often). MCP is just a process and it can crash, and so will the AI agent progress, it all can vanish with a crash.

Well, the new Tasks primitive in MCP (SEP-1686) helps a lot, it gives your AI agents a way to hand off long-running tools, but it doesn't solve the real problem. They don't maintain the state when the server crashes.

In this session, I'll do a live demo of a Kubernetes Auto Healing AI Agent with MCP server and walk through how to wrap MCP tool logic in workflows that survive crashes, restarts, and network failures.
I'll cover how to handle human-in-the-loop approvals inside long-running tools, how to retries and state-management, and how to observe what your MCP tools are doing in production.

I'll be breaking a running server on stage and show you the agent recovering without losing a step. Hence "The Invincible MCP Server"

MCP has become the de-facto "standard" for exposing the external environment to agents, but security has always been a trailing concern, making a lot of platform teams sweat under the collar. Policy checks and tool-call authentication were tacked on quickly, but are quickly being seen are necessary but not sufficient. This session zooms out from single-agent enforcement to the operational challenge security and platform teams actually face in 2026: dozens of agents, hundreds of MCP server connections, multiple clouds, rogue tool registrations, and no centralized visibility into what's running.

This session presents a multi-stage maturity model for enterprise MCP governance, to help take practitioners from "we have no idea what's running" to "every tool call is governed, audited, and compliant with internal policies", and shows how to build the program incrementally, without boiling the ocean in the process and slowing down developer velocity.

Have you ever worried that your new AI Agent might be a little too helpful? Imagine an intern asking an HR chatbot, "What is the CEO's salary?" and the bot, designed to be helpful, promptly fetches it.

As we equip LLMs with tools via the MCP to query internal systems, we introduce a significant data privacy risk if the agent cannot distinguish who is making the request.

In this session, we’ll explore the critical intersection of IAM and AI agents. You’ll see how to implement fine-grained access control and “on-behalf-of” user execution in MCP servers. By securely propagating user context, an agent ensures that when the CEO queries salary data, the data is delivered, but when an intern makes the same request, the system restricts it.

We’ll also dive into the “Human-in-the-Loop” (HITL) pattern, a safeguard that pauses high-risk actions for explicit human approval. You’ll learn how to design secure-by-default MCP architectures using standard authentication flows, zero-trust permissioning, and HITL workflows to keep your AI agents aligned, controlled, and trustworthy.

MCP servers are quickly becoming the default interface between AI agents and production systems.

This speed has a cost. Most teams shipping MCP servers today are repeating the same security mistakes like overprivileged tool definitions, missing input validation, no transport-layer auth, and blind trust in what the LLM sends downstream.

This talk presents a practical security assessment playbook for MCP servers, built from hands-on penetration testing and security assessments of real MCP deployments.

We'll walk through the three-five most common vulnerability patterns seen in the wild.

- tool poisoning
- permission escalation
- transport misconfiguration
- server-side request forgery through tool arguments

For each vulnerability class, you'll see how the attack works, why it slips past code review, and what the fix looks like in practice.

Attendees will walk away with a repeatable methodology for assessing the security posture of any MCP server before it hits prod. Whether they built it or adopted it.

Elicitation is one of MCP's most powerful and least governed features. It lets servers request additional input from users at runtime, enabling richer, more dynamic agent interactions. But in production environments, elicitation also opens a surface for agents to request sensitive data they shouldn't need, bypass approval flows, or trigger unintended actions under the guise of a helpful prompt. This session examines elicitation as a runtime governance problem: what it is at the protocol level, where the security boundary sits between server and client, and how to enforce limits on what agents can elicit without neutering the feature entirely. Drawing on real implementation experience, the talk covers policy patterns for elicitation scope control, audit logging of elicitation events, and the UX tradeoffs of locking it down. Attendees will leave with a clear framework for deciding when elicitation is safe, when it needs guardrails, and how to implement those guardrails in a running MCP deployment.

The MCP spec mandates OAuth 2.0 for HTTP-exposed servers, but most tutorials stop at "add a Bearer token." Enterprise deployments demand more: dynamic client registration, tool-level authorization, token introspection under load, and audit trails for compliance.

This session builds a production-grade MCP server with Spring Boot and the MCP Java SDK, secured by Keycloak. We cover: mapping OAuth scopes to MCP tool permissions, rate limiting per client credential with Bucket4j, wiring OpenTelemetry traces through the MCP request lifecycle, and handling edge cases at scale — token clock skew across distributed agents, graceful degradation when the IdP is unreachable, and preventing prompt injection from leaking privileged tool responses.

Attendees leave with a working architecture adaptable to any identity provider and a clear mental model of where MCP security ends and application security begins.

Breakdown: threat model (3 min), OAuth 2.0 + Keycloak layer (7 min), hardened Spring Boot server (8 min), edge cases from the field (5 min), architecture takeaway (2 min).

Platform engineering has a chicken-and-egg problem: the platform needs adoption to justify investment, but adoption requires onboarding that teams resist when deadlines are tight. Our internal developer platform hit this hard. It serves 4,000+ developers across clouds and managed Kubernetes, yet many teams found the portal too unfamiliar.
We solved it with a second entry point built on MCP. Instead of learning a new UI, developers get 30+ platform capabilities directly in IDE chat, from namespace provisioning and Helm deployments to cost analysis and access management. An MCP App renders forms in chat, developers approve and execute, and a first deployment can happen with almost no onboarding.
This session covers the production architecture: sandboxed iframe-based MCP Apps, Elicitation for structured write approvals, an Adaptive Tool Router that keeps 30+ tool schemas from flooding the context window, a split between deterministic Agent Skills and ReAct reasoning, and a safety layer with a sub-500ms kill switch plus delegated RBAC tied to existing permissions. Attendees leave with a practical blueprint for meeting developers where they already work.

ost MCP servers today ship with a simple setup: plug in an API key or a shared credential, and you're good to go. That works fine for a weekend hack, but the moment you bring MCP into an enterprise, things start to fall apart. You don't want MCP clients storing static usernames and passwords — that's a security incident waiting to happen. You can't tell who did what, you can't enforce fine-grained access control, and your security team is not going to be happy. What enterprises actually need is for users to authenticate through their existing SSO, get access to MCP servers based on who they are and what they're allowed to do, and have every action tied back to a real identity for audit and compliance.

In this talk, we use the OpenSearch MCP Server as a concrete example to show why this matters and what we can do about it. We'll walk through extending the server to support OAuth 2.0 Authorization Code Flow with PKCE and Dynamic Client Registration (DCR), following the MCP authorization spec.

An LLM caught my friend’s condition that doctors took two months to confirm. We asked: what happens when multiple specialised models review the same case together?

We built ConsensusMed on MCP. Each specialist model for a medical domain runs as an independent MCP server, and an orchestrator coordinates their outputs and decides what to trust when models disagree.

Multi-agent clinical systems face real attack surfaces:

- A malicious MCP server can exfiltrate OAuth tokens and impersonate legitimate users
- Prompt injection in clinical reports silently shifts outputs before consensus
- Tampered model weights corrupt findings with no OAuth scope catching it

So we built a trust layer directly into MCP:

- An MCP interceptor proxy redacts PHI using NER before any tool call reaches a specialist server
- The chairman verifies SHA-256 hashes of model weights against Ed25519-signed manifests before spawning
- Specialists run as stdio subprocesses. They never bind to a port. Network access is structurally impossible.

For regulated environments, we built an air-gapped MCP registry that operates entirely offline with cryptographic verification before execution.