Schedule

Large language models are powerful, but without access to tools they remain limited to generating text. The Model Context Protocol (MCP) introduces an open standard that enables AI agents to securely discover and use external tools, data sources, and services.

In this session, I'll demonstrate how to build an intelligent AI agent powered by MCP that can perform real-world tasks such as querying databases, interacting with APIs, managing files, executing DevOps workflows, and orchestrating multiple tools through a single interface.

We'll explore the architecture of MCP clients and servers, tool discovery, context management, security, and deployment considerations. Through a live demonstration, attendees will see how MCP transforms LLMs from conversational assistants into capable software agents that can automate complex workflows while remaining modular, scalable, and interoperable.

Attendees will leave with the knowledge needed to build their own production-ready MCP-powered AI agents.

Building an MCP demo is relatively straightforward. Connecting an AI agent to real enterprise systems is where things get interesting.

Consider an employee asking an agent: “What does our travel policy say, how many leave days do I have remaining, and can you create a travel request for me?” Answering that could require the agent to retrieve documents, query structured data, and call a business system.

In this session, we'll use this scenario to build up a practical MCP architecture with separate servers for knowledge, data, and business actions. Then we'll look at what changes when we treat it as an enterprise system: identity, authorization, least privilege, human approval, auditability, and failure handling.

The goal isn't to present MCP as the answer to every integration problem. It's to understand where MCP fits, where its responsibilities end, and the architecture needed around it to use it safely in real enterprise environments.

MCP gives AI agents a standardized way to interact with external tools, but what happens when those tools can perform consequential actions?

In this session, I’ll explore the security and trust challenges we encountered while building an MCP integration between an AI agent and a real application API.

We’ll examine the boundary between model-generated intent and authorized execution, including OAuth2, HMAC request signing, tool-level authorization, input validation, state-changing operations, confirmations, idempotency, retries, failure handling, and auditability.

The session will show why authentication alone is not enough when an AI agent can invoke tools that change application state. We’ll develop a practical architecture for keeping credentials and authorization outside the model, enforcing deterministic policies around agent actions, and creating an auditable execution path.

The goal is to provide reusable security patterns for developers building MCP integrations for payments, enterprise applications, SaaS platforms, and other systems where an incorrect tool call can have real consequences.

Interoperability standards like FHIR gives health systems a standard way to represent and exchange clinical data. WHO SMART Guidelines make clinical guidance machine readable. But neither defines how an LLM agent should safely discover and invoke clinical capabilities.

This session presents a three-contract architecture: SMART Guidelines (clinical knowledge contract), HL7 FHIR (health-data contract) and Model Context Protocol (MCP) ( agent-to-system contract). Using an on-going Kenyan cervical and breast cancer screening patient registry and clinical decision support system, we show how an MCP gateway can expose narrowly scoped tools for retrieving FHIR patient context, invoking deterministic guideline logic, explaining recommendations, and preparing proposed clinical actions.

The key design principle is bounded clinical agency: the LLM may retrieve, explain and propose, but deterministic CDS remains the clinical authority and side effects require explicit human acceptance. We will cover tool design, FHIR resource mapping, provenance, authorization, auditability, and a reusable pattern for making FHIR-based systems agent-ready without weakening clinical governance.

As developer workflows shift from simple code completion to autonomous IDE coding agents like GitHub Copilot, managing state, background execution, and tool authorization across long-running development tasks becomes a critical bottleneck. This session explores how to leverage MCP’s new stateless core and Tasks API to orchestrate resilient coding agents directly inside developer environments. Attendees will learn how to design MCP servers that grant coding agents access to complex codebases, manage multi round-trip request cycles during refactoring tasks, and execute background builds or test runs without locking the IDE context window or dropping state during session reconnects.

Platform teams face a difficult trade-off: developers want zero friction when connecting coding assistants (Cursor, Claude Code) to tools, while security and SRE demand strict access controls, identity verification, and resource bounds. Without governance, plaintext secrets proliferate in local configs and bloated tool definitions exhaust model context.

This session presents an enterprise platform architecture for operating MCP servers across multi-agent fleets. I'll share our phased adoption roadmap showing how we used read-only log triage to validate cross-client telemetry and build organizational trust before exposing operational APIs.

We'll examine how pairing declarative Agent Skills with MCP servers prunes tool sprawl and separates business heuristics from typed execution. Under the hood, I'll walk through our production Rust implementation using the rmcp Rust SDK, detailing how compile-time schemas and stderr log isolation eliminate wire corruption.

Finally, we'll look at our unified identity architecture, using OAuth 2.1 and CIMD to eliminate workstation secrets across developer fleets.

Most digital consent and privacy models assume a literate user, a personal screen and a clear click to approve. Those assumptions break when an MCP-enabled agent is reached through a shared phone, IVR, local-language voice interface or community intermediary, yet can access identity, health, education, payment or government records and take consequential actions. This talk examines how legal, regulatory and ethical duties can become enforceable boundaries around MCP: purpose limitation, data minimisation, delegated authority, least privilege, policy enforcement, auditable consent, human review and redress. We introduce a RIGHTS framework for last-mile trust and test it against shared-device identity, coerced or mistranslated consent, invisible data linkage, over-broad agent authority and unclear accountability across providers. Attendees leave with a governance pattern connecting law -> policy -> permission -> tool -> action -> audit -> redress.

AI agents are quickly transforming how we build intelligent applications, automate workflows, and enable systems to reason and act autonomously. But with new terms like MCP, ADK, and A2A appearing everywhere in the AI ecosystem, many developers are wondering where to begin.

In this hands-on session, participants will get started with the foundations of modern agentic AI by building a practical currency conversion agent using Google’s Agent Development Kit (ADK). Along the way, we will explore how Model Context Protocol (MCP) enables agents to connect with tools and external systems, how Agent-to-Agent (A2A) communication allows agents to collaborate, and how these technologies come together to power real-world AI applications.

Designed for developers, students, and AI enthusiasts, this session will break down complex concepts into practical building blocks while demonstrating how to create, orchestrate, and extend intelligent agents with modern Google Cloud AI tooling. By the end of the session, attendees will have a clear understanding of the emerging agent ecosystem and the confidence to start building their own AI agents.

MCP servers expose capabilities to LLMs, but who's actually on the other end of that connection?

As MCP adoption grows, authentication and authorisation are one of the most under-specified parts of production deployments. This talk cuts through the ambiguity by comparing the real-world tradeoffs of OAuth, API keys, JWT-based identity, and emerging MCP-native patterns.

We'll look at where each approach breaks down, how to scope permissions to specific tools rather than entire servers, and what "least privilege" actually means when your client is a non-deterministic language model.

At Google I/O 2026, Google introduced WebMCP, a proposed standard for making websites more understandable and actionable for AI agents. In this demo-focused session, we will take a normal web app flow such as event registration, product checkout, or service booking and turn it into an agent-ready experience by exposing structured actions that a browser-based AI agent can understand and execute.

Rather than giving a high-level recap of WebMCP, this session will show what it means in practice: how forms, buttons, and JavaScript functions can become reliable tools for agents, and how developers can design websites that are easier to automate without breaking accessibility, security, or user trust.

Key takeaways

Attendees will learn:

What WebMCP changes about how AI agents interact with websites.
How to expose website actions in a structured, agent-friendly way.
How to redesign common Kenyan web flows such as registration, booking, checkout, or service discovery for agentic use.
What security, permission, and UX questions developers should consider before making a site agent-ready.

MCP servers describe their tools to an agent using names, descriptions, and parameter schemas, and the client feeds that text straight into the LLM's context, where the model treats it as trusted instruction. That single design fact opens an attack native to MCP, often called tool poisoning: a malicious or compromised server hides instructions inside a tool description, and the agent obeys them.

We poison a tool so a harmless-looking get_weather call coaxes an agent into leaking a credentials file, then show why the obvious fixes are only partial and what defense-in-depth actually requires. We finish by re-running the attack against a hardened setup.

I build hospital management software for small and rural facilities in Kenya, Nigeria, Somalia and Indonesia, where cloud models are often not an option. Connectivity is weak, budgets are small, and patient data is sensitive. Prototyping LLM features in that environment taught me one lesson: the context window decides how effective a small local model is. On an 8GB GPU that budget is physical model weights plus KV cache and every trick that makes a model fit (quantization, cache compression, shorter context) carries a fidelity price. Tool calls pay it first. Using dhis2-mcp, an open-source MCP server for DHIS2, I show how to size a model for your hardware, how to define tools a small model can handle, and what holds and what breaks when Qwen and Gemma drive real tools through LM Studio on 8GB

AI agents are increasingly able to use tools that access databases, APIs, files, and other systems. But how do we make sure an agent can only access what it is supposed to?

In this talk, we’ll explore a practical approach to enforcing tool-level access control at the MCP server level. Using Hodari, a production travel assistant with four AI agents and three MCP servers, we’ll look at how sensitive data can be protected even when agents have access to powerful tools.

The talk will show four simple mechanisms for enforcing these boundaries, including access checks, restricted fields, protected records, and automated tests that inspect the entire tool registry.

We’ll then build a small example from scratch, intentionally introduce a tool that violates the access rules, and see how the test detects it automatically—even though the test was written before the new tool existed.

The session will also cover the limitations of this approach, including what happens when the application itself is compromised and when this level of access control may be unnecessary.

Attendees will leave with a practical understanding of how to design and test access boundaries for MCP-based AI agents.

Title: tools/list Is Not an Agent Interface: Progressive Disclosure for MCP Servers

Abstract:

An MCP server can be compliant and still give an agent a bad interface. After several live demos with the Apache-2.0 neo4j-labs/agent-memory project, I stopped treating its MCP surface as a flat API. The server offers a six-tool core and a 16-tool extended profile. The larger profile spans conversation history, entities, graph export, observations, reasoning traces and read-only queries. Returning everything from tools/list is legal. It consumes context and creates overlapping routes through the API. A workspace-scoped identity may also see operations it cannot use.

I’ll reproduce a bad tool choice, then repair the interface with capability profiles and least-privilege scopes. Deterministic capture moves outside model choice. Structured results reduce ambiguity, while Skills over MCP handles progressive instructions. Attendees leave with a practical rubric for choosing between tools, resources, skills and invisible plumbing. The goal is an MCP server that can grow without making agents less reliable or widening its permission surface.

In the first two months of 2026 alone, researchers filed more than 30 CVEs against Model Context Protocol servers, clients, and infrastructure, [Cycode]

As organizations adopt MCP to power increasingly autonomous workflows, they also introduce a new attack surface that traditional application security models were never designed to address.
Rather than reviewing the OWASP MCP Top 10 as a checklist, this session will explore it from an attacker's perspective. Through realistic attack scenarios, we'll examine how seemingly small security gaps like excessive tool permissions, insecure trust relationships, exposed credentials, or poorly governed MCP servers can be chained together to compromise AI agent ecosystems.
For each attack path, we'll map the scenario back to the relevant OWASP MCP Top 10 category and discuss practical mitigations developers, security engineers, and platform teams can implement. Beyond technical controls, we'll also explore how governance, least-privilege access, policy enforcement, and continuous monitoring reduce the likelihood and impact of these risks.

Attendees will leave with a deeper understanding of the security assumptions behind MCP.

Most MCP tutorials assume you control the backend. In public-sector and telco integration work, you usually do not. You may have a read-only endpoint, change-request cycles measured in months, strict data-residency requirements, and security teams unfamiliar with a protocol where the client decides which function to call.

This talk draws on adoption patterns from deployments where MCP was retrofitted onto systems that could not be modified: enterprise software, real-time translation infrastructure for a mobile network operator, and sovereign retrieval deployments for state governments.

We will explore the recurring patterns: wrapping instead of rewriting; how far a normalizer can take you before a real integration layer is needed; multi-tenant isolation when tenants are separate government entities; authentication and audit expectations driven by procurement and their implications for tool-level logging; and tool contracts as reviewable artefacts, including lessons from a production incident where a description change altered agent behaviour. We will also examine the organisational work required to build trust in non-deterministic tool selection over sensitive data.

Feast, the open-source feature store, shipped its first MCP server the easy way: fastapi_mcp mounted straight onto the Feast API server. One process, one port, one set of dashboards, and no way to tell an agent's tool call from a human's HTTP request. When load spiked, nobody could say who caused it.

This talk is the story of moving that server off the app and onto FastMCP as a standalone stateless service, and the two problems the migration exposed.

Observability turned out to be tractable. A separate MCP surface gave us a clean boundary to instrument: OpenTelemetry context propagated from agent to MCP server to Feast, per-tool-call audit records, and agent traffic finally distinguishable from human traffic in the same trace view.

Identity did not. Going stateless broke the session assumptions the old server leaned on, and the harder question – is this call the agent, the user, or the agent acting for the user, and what should each be allowed to read – has no settled answer in the spec today.

I will show the open-source OpenAPI-to-MCP migration toolkit we built, the upstream Feast changes, the traces, and an honest list of the identity gaps I want the MCP community to close.

MCP's July 2026 spec quietly did two things to observability. It deprecated protocol-level logging in favor of OpenTelemetry, and it deleted the session ID with no deprecation window.

This session covers what MCP observability looks like now that the protocol has handed the job to OpenTelemetry. How the MCP semantic conventions shape a real trace from agent to client to server to the database behind it, why traceparent as a required header changes what a gateway can see without parsing request bodies, and how to rebuild correlation from the authenticated principal and explicit workflow IDs once the session is gone.

We'll trace a slow tool call end to end and find the actual bottleneck, then I'll finish on the parts that are still awkward like context propagation over stdio, and how much of a tool's input you can safely put in a span.

An agent begins a multi-step workflow, calls an authoritative registry, asks the user for confirmation — and the network disappears. When connectivity returns, the hardest question is not how to reconnect but what has already happened. This talk treats intermittent connectivity as a first-class agent-design problem. Using a citizen-service workflow, we examine how MCP clients and gateways can cache safely, defer non-critical work, resume with explicit state, prevent duplicate side effects, distinguish retry from replay, detect stale authority, and reconcile local state with the source system. We classify operations into safe-to-cache, safe-to-retry, safe-to-queue and never-offline, then show how channel handoff can return results later through voice, SMS or web. Attendees leave with a CACHE-DEFER-RESUME-RECONCILE pattern and a failure-injection checklist for testing MCP systems beyond stable broadband.

Any agent that can query a national registry can also mine it. That tension, not the protocol, is what makes DPI hard.

We put MCP over EduCert, Nigeria’s school certificate platform built on Sunbird RC, so a voice agent can take a student ID by phone and explain the verified result to parents, guardians and teachers in local languages. A registry that previously needed a browser and English now answers a phone call, with AI-generated improvement pathways attached.

The presentation will walk through the decisions and what each one costs. Why the tool surface is four identifier-only tools, and the things an agent can no longer do because of it. Why enumeration is impossible in the schema rather than forbidden in the prompt. Why a bridge between two identifier namespaces would look like a convenience while quietly deleting an access check.

Plus, what we have not solved: one shared credential, and what that does to your audit trail.

You will leave with a checklist for scoping tool surfaces over registries you do not own.

AI agents make judgment calls all day. They route, price, approve, and escalate, yet each decision evaporates the moment it is made. Agents cannot recall how similar cases were handled, cannot explain their reasoning after the fact, and cannot stay consistent with one another. The result is drift: unauditable agents that are hard to trust.

This session introduces NANDA Context Graph, an open source, hosted decision memory for MCP agents. Every decision becomes a node in a causal graph (Neo4j): the inputs an agent saw, its reasoning steps, the MCP tool calls it made, and its output, with causal links that follow decisions across chains of agents. Before acting, an agent recalls semantically similar precedents via embeddings. After acting, it records its decision as new precedent. Anyone can ask why and get the full causal chain back.

Integration is minimal: one SKILL.md and three REST endpoints (recall, record, why), nothing to install.

You will see the graph model, a live demo of an approval agent consulting precedent before deciding, and how decision memory complements the OpenTelemetry observability direction of MCP. You will leave able to give your agents a memory of why.

Internationalisation has been a major gap in the modelcontextprotocol, with the vast majority of servers only targeting English. This gap excludes much of the world from a first class agent experience. Finally this is being resolved, this session will explain why it is needed, how to ship this in MCP servers and clients, what parts should be translated and the footguns and gotchas to avoid.

As well as implementation, there will also be a demo showing how it works in practice, and advice on leveraging AI for initial translations when you are getting started.

This is something we can and should solve to make MCP more inclusive, and truly global.

Most "smart" home assistants aren't smart about your privacy, your connectivity, or your wallet. They need a live connection to someone else's cloud, ship your voice to a data center you'll never see, and go quiet the moment your internet does. Goose In A Pond is the alternative: a fully local, privacy-first smart home assistant our team built on Goose, AAIF's open-source AI agent framework and MCP client. Every part of it, voice recognition, language understanding, memory, device control, runs on hardware you can hold in your hand, like an NVIDIA Jetson Orin Nano (it even runs on a Raspberry Pi 5). Nothing leaves the house. And because it's built on an open agent, it's yours to inspect, extend, and improve, not licensed to you by a vendor who can change the terms whenever they want. In this talk, I'll share what it actually took for a five-person team to build a smart home AI that holds its own against commercial cloud assistants, including in the low-connectivity conditions those products quietly assume away. You'll see how we taught Goose to listen for its own name, control everything from bulbs to devices with no API at all, and get better over time without ever phoning home, plus the MCP extensions we're open-sourcing so anyone in the Goose community can build their own pond. Because democratizing AI shouldn't just mean cheaper access to someone else's cloud. It should mean that anyone, anywhere, with an idea and a dev board, can build something that's genuinely theirs.

Over the last few months we at OpenAI have been developing internal case studies on E2E software factories driven entirely by agents and following the constraints of:
1. No Token budgets — leveraging100+m tokens per minute of GPT 5.5 Pro
2. No human intervention — granting full production authority to agents
3. Complete K8/Open source hermeticism

As the original implementing team of MCP at OpenAI we have heavily utilized it is a a broad interface for these agents to take a degree of control on the software development process beyond simply coding. Agents:
– Collaborate on proposals
– Implement and review code
– Oversee testing and qualification
– Control the entire promotion and release process
– Perform active monitoring and remediation in production
All through MCP layers on top of observability and release stacks.

This talk aims to help show what breaks, where the remaining gaps are, and where strong areas to focus are once tokens are not a concern.

Most AI applications still behave like chatbots: users type a request, the model returns text, and the application does very little with the result.

A new generation of agentic standards is changing that.

MCP allows applications to expose tools and data to agents. WebMCP brings those capabilities into the browser, allowing web applications to register structured actions that agents can discover and invoke. A2UI enables agents to generate rich, interactive interfaces using trusted components rather than generating arbitrary code.

• MCP gives the agent access to backend tools and services.
• WebMCP exposes browser-level application capabilities.
• A2UI allows the agent to generate a contextual interface for the user.
• The host application retains control over components, permissions, validation and execution.

In the live demo we'll see how an agent receives a natural-language request, chooses the appropriate tools, retrieves structured data, generates a dynamic interface, and safely executes a user-approved action.

The goal is to show how developers can build software that is interactive, agent-aware and governed by design.

Background: MCP is moving from experimentation into production, but edge AI is under-explored. Small language models and inference agents on KubeEdge nodes can reason locally, yet connecting them to device data, metrics, and management tools has stayed ad hoc, a gap this session addresses.

Methodology: We deployed SLM inference agents as MCP clients on KubeEdge edge nodes, built local MCP servers exposing device-twin, metrics, and GraphQL/PostgreSQL-backed telemetry tools, then measured tool-call latency, failure modes, and resource use across nodes.

Outcome: MCP reduced coupling between agents and device backends and simplified multi-tool orchestration, though intermittent connectivity, schema drift, and cold-start latency emerged as real constraints, visualized via latency heatmaps.

Conclusion: MCP is a practical, still-maturing integration layer for agentic AI at the edge; we share concrete failure patterns, design trade-offs, and open questions for the ecosystem to build on.

MCP makes it easy to expose more tools; small models make that abundance expensive. On-device and low-compute agents have limited context, weaker tool-selection accuracy and tighter latency, memory and power budgets. This talk explores how to design an MCP tool surface for models that cannot reason reliably over hundreds of schemas. We examine contextual tool loading, hierarchical discovery, domain routing, tool-description compression, deterministic pre-routing, confidence thresholds, local/remote model handoff and graceful fallback when cloud reasoning disappears. A worked citizen-service example starts with a large cross-domain tool catalogue and reduces it to the minimum tool set needed for one task, then tests what changes when the model and network budget shrink. Attendees leave with a practical toolbox for matching MCP exposure to model capability rather than assuming frontier-model resources.

Nigeria faces a growing challenge of managing chronic conditions beyond the clinic. Hypertension illustrates the scale: about 22 million adults aged 30–79 live with the condition, yet only 13% have it controlled.

mDoc's CompleteHealth™ platform and AI health coach, Kem, support over 186,000 members. But important health information shared in conversation could guide advice without becoming part of a member's health record or connecting them to the next point of care.

We built an MCP layer that amplifies Kem's connection to the wider CompleteHealth™ ecosystem. Information shared in conversation can update a member's health metrics and inform future interactions. When further care is needed, the same layer can use NaviHealth to identify suitable nearby facilities and return those options within the conversation. Tool permissions, validation and session limits help protect member data and control what actions can be taken.

In its first months in production, 91% of 742 tool calls completed their intended actions, including recording blood pressure readings at Grade 2 severity or worse, turning information that might otherwise remain only in conversation into part of continuing care.

Zuzi is a WhatsApp-based support agent for GBV survivors in South Africa, transitioning from a retrieval-only architecture to a multi-agent one. Retrieval alone produces two failure modes: over-triggering, ordinary distress receives the same hardened script as genuine crisis, and under-response, real crisis surfaces a passive, generic reply. Uniform hardening is not safer; it teaches survivors the system cannot distinguish distress from danger, reducing disclosure when it matters most.
Our architecture has three coordinated agents, general-purpose, high-risk, and handover, with a router assigning each turn to the agent equipped to handle it. MCP carries state across handover, so risk classification, history, and escalation status transfer without loss.
This talk maps where MCP fits, and where its role ends. We walk through MCP as the shared interface between agents, carrying state and retrieving responses across growing risk tiers. We discuss our deliberate boundary between MCP connective infrastructure and the actual classification and routing logic, which remains a modeling problem MCP doesn't solve. We close with how co-creation led to the evaluation criteria of classifications.

Modern smart buildings rely on thousands of resource-constrained Microcontroller (MCU) nodes (temperature, occupancy, CO2, light sensors) that speak serial protocols like Modbus RTU or BACnet MS/TP. However, LLMs speak JSON over HTTP/SSE. This talk details our journey building a lightweight MCP Server that acts as a "Protocol Bridge" between these binary registers and semantic MCP Tools.

An MCP tool call triggered by text starts with an apparently discrete instruction. A voice client starts with uncertainty. “Fifteen” can become “fifty”; a person or village name can map to the wrong record; code-switching can alter intent. In read-only lookup this is inconvenient. In payments, eligibility or application submission it can be consequential. This hands-on workshop introduces a Voice-to-MCP gateway that treats ASR confidence, semantic ambiguity, tool consequence and reversibility as execution inputs. Participants work through noisy speech-to-text scenarios, map confidence to execution policies, decide when to call, clarify, constrain or refuse a tool, and design confirmation checkpoints for high-impact actions. We end with a reusable risk matrix and gateway pattern for speech-first MCP clients.

AI agents can write code and call tools, but letting one change real infrastructure takes more than handing it cloud credentials.

I built MCP Deployment Lab, an open-source deployment controller that sits between an AI agent and a cloud platform. To the agent it is an MCP server; to the platform it is an MCP client. It separates read-only planning from infrastructure mutation: an agent can inspect a target and prepare a plan, but changing anything requires an approved plan and passing policy checks. The design is provider-agnostic; today it deploys through PipeOps, where I work as Developer Relations Lead.

Live sandbox runs exposed two failures in my own design. PipeOps created and ran an application, but my controller could not extract a durable project identifier and reported FAILED; the safer state was UNKNOWN. In another run the container started normally while a readiness probe failed on the configured port, showing how flattening provider evidence into prose destroys recovery signals.

The controller also served MCP 2026-07-28 upstream while negotiating 2025-11-25 downstream. This talk covers the architecture, what broke, and the patterns behind safer agentic deployment.

Enterprise adoption of AI agents often stalls when attempting to interface with existing legacy platforms, ERPs, and strict internal compliance frameworks. This session presents a practical case study on integrating the Model Context Protocol (MCP) into internal platforms and developer workflows to bridge traditional infrastructure with LLM tools. We will explore architectural patterns for wrapping legacy APIs and database services with MCP servers, establishing governance and permissioning layers, and maintaining full audit trails without rewriting core business logic. Attendees will leave with actionable strategies for incremental MCP rollout, managing change across engineering teams, and ensuring enterprise-grade compliance in agentic workflows.

MCP moves the trust boundary into text the model reads: tool descriptions, retrieved resources and server metadata can become instructions. This 25-minute session turns that problem into a repeatable threat-modeling workflow.

Using a host with multiple agents, clients and servers, we draw data flows, mark trust boundaries, apply STRIDE, and use MAESTRO to follow attacks across model, data, framework, identity and infrastructure layers.

Two worked paths make it concrete: a tool-description rug pull in which tools/listchanged silently replaces an approved hash, and indirect prompt injection hidden in a Confluence page that triggers a legitimate confluencecreate_page call. We trace each from entry point to impact and derive controls: hash-pinned manifests, per-hop audience-bound tokens, bounded tools, output validation, egress allowlists and correlated audit events.

The demo converts the model into four tests: reject implicit grants, tokens in URLs, refresh-token replay and tokens for another server. Attendees leave with an MCP-MAESTRO-STRIDE matrix and review checklist. This extends my “Secure MCP Servers in Production” talk at MCP Dev Summit Seoul 2026.

Most MCP conversations focus on giving agents more tools. My recent technical writing has focused on the other half of that problem: how to make agent work verifiable enough to trust.

This talk is about using MCP not just as an integration layer, but as a verification harness for AI agent loops. In my work on verifiable loops, structured outputs, and agentic coding workflows, the recurring failure mode is not lack of autonomy. It is that agents can act without leaving enough evidence behind: what they saw, which tool they used, what artifact changed, why they decided they were done, and whether the result was checked.

I’ll walk through practical MCP patterns for inspectable workflows: tools with narrow authority, structured outputs instead of ambiguous text, artifacts and intermediate state attached to every loop, separation between “agent can request” and “agent can execute,” and MCP servers that make verification cheap.

Grounded in lessons from coding workflows, UI generation loops, and fast structured inference, this talk shows MCP builders how to design servers that help agents do useful work while making that work reviewable, reproducible, and safer to automate.

When you install an MCP server, you're not just adding a feature. You're introducing another piece of software into your agent's environment that may access files, APIs, databases, or other capabilities depending on the permissions you give it. So how do we know that the MCP server we connect to is safe?

We already think about software supply chain security when using open source libraries, packages, containers, and CI/CD dependencies. MCP servers introduce a similar problem, but with a much more direct path from software to actions taken by an AI agent.

This talk looks at the MCP server as a software supply chain dependency. We will trace the path from its repository and dependencies through build and deployment, to the MCP client and AI agent. We will examine where trust can be lost through vulnerable dependencies, compromised builds, malicious updates, weak provenance, and untrusted tool providers.

Finally, we will explore practical ways to establish trust in MCP servers using dependency security, SBOMs, provenance, artefact integrity, signing, and repository security.

MCP gives servers a generic contract for tools: names, descriptions, typed inputs and outputs, and behavioral hints including readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. Memory exposes edge cases these contracts do not fully capture.

A memory write is not just an API mutation. The same fact can arrive in different words, so semantic deduplication differs from request-level idempotency. Retrieval is often ranked rather than exact, so a successful search can still miss the memory an agent needs. Updates may replace stored memory rather than change structured fields. Deletion and promotion introduce irreversible lifecycle changes. And scope, whether memory belongs to a user, agent, run, or shared space, must not become an authorization boundary just because the model supplied it.

This session compares three approaches to agent memory in the MCP ecosystem, Mem0, Letta, and Meko, looking at their tool surfaces, retrieval models, mutations, lifecycle, and scope.

Attendees leave with a practical checklist for designing or auditing MCP memory servers, covering idempotency, retrieval, mutations, destructive operations, and authorization.

Africa's DPI is being built registry by registry: identity, credentials, payments, health records. Most is reachable only through web portals and English forms, excluding much of the population it was designed to serve. MCP can change that. A registry exposed as tools can be reached by an agent, and an agent by a phone call, in a local language, on any mobile phone, with no data plan.
The facilitators have shipped this: an MCP server over a national credentialing registry, and local-language voice models on government platforms. The first 20 minutes of the workshop walk five layers: authoritative registries, MCP orchestration, the AI knowledge overlay, local-language delivery, and citizen channels with and without internet. What each costs, and where it breaks.

A lot of "agentic commerce" demos out there show an LLM calling a payment API directly. These demos work until the agent gets something wrong, the network retries, or there's a need for a HITL in the middle of transacting.

This talk shows how to treat every transaction initiated by an agent as a stateful intent rather than a single API call. We get to journey through a payment intent state machine that separates "deciding" to pay from "authorising" to pay from "executing" the payment; a token issuance model that prepares and reserves a transaction before any PIN or human confirmation exists; and a policy layer that adds guardrails to what an agent can spend without confirmation from you.

We'll also cover how this works with real settlement (routing through multiple rails, a settlement status poller reconciling against actual bank/payment-rail state rather than trusting the initiating call, and how a tool registry mediates between the LLM's intent and what code is allowed to execute).

From all this, we get an architecture where agents can safely act with financial autonomy inside policy bounds, without failing modes becoming an issue in prod.

As MCP brings AI agents closer to enterprise systems, an important architecture question emerges: where should the agent boundary actually live?

An enterprise may already expose capabilities through APIs and integration layers that handle authentication, transformation, orchestration, error handling, observability, and access to systems such as CRM, ERP, databases, and legacy applications. Introducing MCP does not eliminate those responsibilities, and turning every existing API into an MCP tool directly may add a new layer of complexity.

This session explores how MCP can fit into an existing enterprise integration architecture without duplicating responsibilities or bypassing established controls.

Using practical architecture scenarios, we will examine the boundary between MCP servers, APIs, integration platforms, and backend systems; which responsibilities belong at each layer; when an existing API should become an MCP-accessible tool; and when it should not.

Attendees will leave with a practical framework for designing MCP alongside existing enterprise integration capabilities.

MCP's tool model has an implicit shape: call a tool, get a result, act on it. Payments across much of Africa don't fit that shape. A bank transfer to a virtual account settles asynchronously, confirms over a window measured in seconds to minutes, and arrives by webhook rather than in a response body. Mobile money adds a human in the loop, a USSD prompt on a device the agent cannot see.
This talk covers what breaks when you wrap those rails in an MCP server: tools that must return "pending" as a first-class success rather than an error, retries that create duplicate payouts because a model reads a timeout as a failure, and reconciliation with no human left at the end of it checking a dashboard.
I'll walk through the tool schema and error semantics we landed on at Monnify, what we got wrong first, and what generalises to any rail that settles later.

Connecting an AI agent to one MCP server is straightforward. Connecting it to several is where the real engineering problems begin.

In this session, I will share lessons from building a multi-server MCP agent that needs to discover tools, choose the right server, manage context, recover from failures, and safely execute actions across different services.

We will look at practical challenges including tool selection, overlapping capabilities, context growth, authentication, latency, retries, permission boundaries, and observability.

Rather than introducing MCP from first principles, this talk focuses on what happens after the demo works. Attendees will leave with practical patterns for designing more reliable MCP-powered agents that interact with multiple tools and services.

Model Context Protocol (MCP) is becoming the standard way AI models interact with tools and applications. However, moving from demos to production requires secure, scalable, and reliable architectures.

This session explores how to build intelligent fintech payment agents using MCP, Java, and M-PESA-inspired integrations. Attendees will learn how AI agents can securely interact with mobile money and enterprise APIs while meeting enterprise requirements for security, auditability, and resilience.

Topics include:

MCP architecture and tool orchestration
Designing MCP servers for fintech use cases
Integrating AI agents with M-PESA and REST APIs
Authentication, authorization, and trust models
Production patterns: retries, rate limiting, observability, and fault tolerance
Best practices for enterprise deployment

By the end of the session, attendees will have practical patterns for building secure, scalable, and production-ready fintech agents with MCP

Multi Round-Trip Requests (MRTR) is the new core pattern in MCP 2026-07-28 for
building safe, auditable agent interactions. Unlike the old model where servers
initiated LLM sampling and root queries, MRTR flips the model: servers signal when
they need input by returning an input_required result, clients handle retry logic,
and requestState provides correlation across attempts.

In this talk, we'll walk through why MRTR exists, how to build it correctly
(and the subtle mistakes that break safety), and real code examples from production
deployments. You'll leave with a tested pattern for user confirmations, permission
checks, and complex elicitation flows that actually work in multi-agent systems.

Topics covered:
– MRTR anatomy: input_required results, inputRequests, requestState
– Building a safe approval workflow in an MCP server
– Common pitfalls: state correlation, idempotency, timeout handling
– From server to agent: how hosts interpret and retry MRTR flows
– Debugging tools and observability patterns