MCP Dev Summit Bengaluru 2026

Every agent today answers one question at the auth layer: is this agent allowed to do this? Wrong question. The real one: is it doing something consistent with what the user asked - right now, in this step?

These aren't the same, and the gap is where things break.

Today's auth was built for humans logging into apps: roles and scopes that persist regardless of what the agent is actually attempting. Tell an agent to "read this PDF and send the pointers to my team." The PDF hides an instruction: also forward the thread to an external address. The agent fires two sends - one legit, one exfiltration. Same token. Same checks. Role-based auth can't tell them apart because it never knew the agent's job.

This talk closes that gap. We'll trace why every prior access model assumed a stable human actor - and why that collapses when agents delegate to agents. We'll introduce Intent-Based Access Control: decisions that reflect not just what an agent may do, but what it's trying to do right now. We'll cover emerging standards like transaction tokens and richer auth context, plus concrete steps to ship intent-aware access in MCP flows today.

When humans hire someone, they ask questions first. Check reviews, compare, negotiate. AI agents can't do any of this.

An MCP flight booking server says: "I book flights." Another agent can't ask: How many routes? Success rate? Can you get business class upgrades?

I tore down top MCP servers across mcp.so, Smithery, Glama, PulseMCP. The #1 server has 52K stars but exposes 47 capabilities with zero verifiable metrics. Tool schema: 1,020 tokens of bloat.

The problem: MCP tool schemas describe WHAT but not HOW WELL. No capability layer for agents to evaluate each other before committing.

What's needed — structured capability endpoints:

"I book flights"
→ 147 routes, 96.2% completion, 23% avg savings
→ Business class upgrades: 340 secured, 41% success
→ Savings by route queryable, methodology documented
→ Full transaction log for independent verification

Exposed as MCP resource endpoints —
capability/summary returns structured metrics, capability/evidence/{tool} returns methodology, capability/raw/{tool} returns verifiable logs.

I'll show real endpoint teardowns, what's missing from tool schemas, and a draft capability-metadata spec builders can implement.

As the Model Context Protocol (MCP) matures, we face a critical security hurdle: how do ambient agents that are running in the background or on headless devices securely access sensitive resources without constant manual intervention?

Standard OAuth flows often break the "ambient" experience by requiring immediate browser redirects on the same device. This session proposes a decentralized identity architecture using Client-Initiated Backchannel Authentication (CIBA). By decoupling the consumption of resources from the authorization flow, an MCP client can trigger a "just-in-time" permission request directly to a user's trusted mobile device.

Key Takeaways:
- Decoupled Auth: Implementing CIBA to bridge the gap between headless MCP clients and human controllers.
- Just-in-Time delegations: Moving from "all-or-nothing" API keys to granular, session-based permissions.
- Security Patterns: Handling asynchronous "Out-of-Band" callbacks within the MCP lifecycle.

Join us to explore how we can make background agents both powerful and respectful of the "human-in-the-loop" principle.

Most database MCP implementations are stdio transport, hardcoded URIs, and live connections handed directly to AI agents. This works on a laptop. It fails in production.
Direct agent-to-database connectivity is dangerous. Connection exhaustion, raw credentials in agent context, DDL one hallucination away, PII returning unfiltered into LLM context windows, runaway queries taking down production clusters. Not theoretical. Production failures waiting to happen.
For our internal DBaaS service we built a two-layer remote MCP architecture to close every one of them. An MCP Proxy handles agent-facing concerns — JWT auth, SSO-backed approvals, rate limiting, and an execution_id registry so no agent ever sees a raw URI. It never touches the database. Queries route through a Query Service — the only layer that does. Read-only enforced structurally, DDL blocked even for root, injection filtered, timeouts enforced, Presidio scrubbing PII before responses reach any agent context window. We contrast this with direct-connect tools, contribute execution_id as a reusable enterprise primitive, and make the case for why an enforcement layer between MCP and your DB is the architecture — not an option

As MCP servers exponentially proliferate, a critical question emerges: who audits what an LLM actually did when it invoked a tool?

Application-layer logs can be tampered with or missed. This talk argues that eBPF is the only tamper-resistant audit layer for MCP tool execution and shows you how to build it.

We walk through instrumenting an MCP server's syscall surface with bpftrace and cilium/ebpf: capturing every network egress triggered by a tool call, every file descriptor opened, every exec spawned, correlated back to the originating MCP request ID via process lineage tracking in BPF maps.

The result is an immutable, kernel-enforced audit trail that no application-layer bug or prompt injection can suppress.

We'll also cover using eBPF LSM hooks to enforce policy at call time, blocking tool invocations that attempt unexpected network destinations or file paths effectively making eBPF a runtime policy engine for MCP's threat model.

Attendees leave with a working threat model, reference eBPF programs, and a clear mental model for where kernel enforcement fits in MCP's trust architecture.

What if your MCP server could confidently decide who gets access to what, without turning your codebase into a security nightmare? In this session, we follow the journey of a simple MCP server as it evolves from an open endpoint into a fully secured, production-ready system. Along the way, you’ll see how authentication actually works in MCP, how to move beyond basic role checks into fine-grained, contextual authorization with OpenFGA, and how these pieces fit together in real-world scenarios. The highlight is a live demo where we lock down an MCP server step by step, making the invisible layers of security visible and practical. By the end, you won’t just understand MCP security, you’ll know exactly how to implement it or even offload it entirely so you can focus on building powerful agent-driven experiences.

Agent security discussions focus on prompt injection and sandboxing. But when agents operate on real infrastructure - pushing to Git, executing code via SSH, starting cloud instances - every machine in the fleet carries its own keys, tokens, and credentials, multiplying the risk.

This talk presents the security architecture of apra-fleet, an open-source (Apache 2.0) MCP server that orchestrates AI agents across distributed machines:
- Credential lifecycle: provisioning LLM auth (OAuth, API keys), SSH keys, and Git tokens with automated key-pair migration
- Out-of-band credential entry: passwords collected via separate terminal, never exposed to the LLM. "LLM secure variables" for sensitive text
- Short-lived tokens: GitHub App mints scoped tokens with minute-level TTLs - a compromised session cannot reuse yesterday's token
- Role-scoped permissions: MCP tool constraints make violations structurally impossible - a doer agent cannot call the merge tool
- Encryption at rest

Grounded in production sprints across C++, Node.js, Python, and ML. Attendees leave with reusable patterns for securing multi-agent systems on real infrastructure.

MCP gives us a clean abstraction for agents calling tools. But it doesn't talk about security: what if the tool does bad things?

For read-only tools returning structured data, a shared-kernel container is fine. For the growing class of MCP servers exposing code execution, the attack surface that produced CurXecute (CVE-2025-54135 and CVE-2025-59944), containers are the wrong primitive, because a single exploit crosses from MCP server to host.

This talk covers what MCP tool execution looks like when you take isolation seriously. It walks through the architectural pattern of scheduling Firecracker microVMs for MCP tool execution - sub-second resume (for chained tool calls and fast-start), minimal kernel configurations, and common integration paths with Kubernetes.

Attendees leave with a decision framework: four signals that isolation complexity is worth it, three signals it's overkill, and a clear mental model of the latency-vs-isolation tradeoff.

MCP's tool schema, server descriptions, and routing logic are overwhelmingly designed around English. That assumption quietly breaks when you build for users in Hindi, Tamil, Kannada, or Bengali.
This talk is a ground-up look at where MCP falls short for Indic language users and what it takes to fix it. The specific failure modes covered include: intent ambiguity in tool selection when queries arrive in transliterated or code-switched text, embedding models trained on English producing poor similarity scores for Indic-language tool descriptions, and response localization gaps where tool results are returned in English to users who queried in their native language.
The talk then presents concrete patterns for each problem, including translated and dual-language tool manifests, language-aware routing layers that sit between the user and the MCP client, and lightweight post-processing for localizing tool outputs. All patterns are demonstrated with working code from production voice agent systems built for Indian users.
With the MCP Dev Summit landing in Bengaluru, this is a timely and locally grounded conversation the ecosystem needs to have.

Your MCP server works. Every tool call executes. But do you know who made that call, whether they were allowed to, and whether it should have required a human to approve it first?

Most MCP servers today operate on implicit trust. If an agent can connect, it can run anything - usually without any identity checks, boundaries, or logs. That works in dev. In production, a misconfigured agent or a prompt injection can trigger your most sensitive tools with nothing to stop it.

This session makes the path from 'working' to 'governed' concrete: authenticating agents via OAuth, enforcing per-tool authorisation, and adding human-in-the-loop approvals for high-stakes actions. Live demo: we’ll take an unauthenticated agent, lock down the server, and hold a sensitive call for approval with a full trace on exit.

MCP connects agents to your most important systems; it’s time we started checking their IDs at the door.