OC3 2026 | The Weakest Link in AI: Hardening MCP Servers with CC with Pawan Khandavilli

0:07 (upbeat music)- Hello, everyone, thank you so much for joining.

0:17 I'm Pawan Khandavilli, I'm a Senior Product Manager

0:20 on the Azure Confidential Computing team at Microsoft.

0:24 And today, I'm here to talk about

0:26 how confidential computing technology that this community has

0:30 been building and taking forward solves a new

0:33 and urgent problem in the AI space.

0:36 Just before I begin, this is not a Microsoft product.

0:40 We use experts here are on my own,

0:42 of on my own and cannot represent Microsoft's (indistinct).

0:45 So I just want to make sure we get the disclaimer out of the way.

0:50 And so the talk today will have three main portions, right?

0:55 Like we have the problem on why MCP servers are uniquely high

1:00 value targets and why some of the existing controls might not work.

1:05 The solution on how do we close the gap with using

1:08 confidential computing as a defense in depth and the framework

1:15 on how to think beyond trust execution environments and confidential

1:20 computing to protect the full threat surface of pure MCP servers.

1:24 So that's where the talk will go today, so let's get started.

1:30 So for those...

1:32 This is bit of an orientation slide for folks who are not following this pace.

1:36 So confidential computing...

1:38 Sorry, MCP servers short for Model Context Protocol server

1:44 are sort of the USB-C of agent tooling, right?

1:47 It's like a universal interface for LLMs and agent high assist

1:51 to sort of talk to the external world and do real-world actions.

1:57 Like this is one of the reasons why adoption is exploding.

2:01 Almost every major AI framework is adding MCP

2:05 support and that gets it to the second row,

2:09 where to talk to these external world and have all these accesses,

2:14 so you need credentials, right?

2:16 Like it could be GitHub, AWS, Slack, Stripe,

2:20 whatever it is that you need to access and do things outside in the real world,

2:25 you need that access.

2:26 So we have a credential aggregation problem here.

2:31 And just going beyond that, like LLMs,

2:33 the LLM intent is transferred into the real

2:37 world through MCP server execution as I mentioned before,

2:42 and lots of credentials, and sometimes (indistinct) Slack can be part

2:47 of this, which can be a single point of compromise.

2:52 So the right way to think about MCP is not as a two-layer,

2:57 but a capability system.

2:58 That means you need permissioning,

3:00 isolation, auditing, and blast radius control.

3:02 And I'll be talking about isolation and blast

3:06 radius control through the stock and we can,

3:08 at the end, touch upon some of the other things we can do.

3:14 So this slide, I'm trying to bring together

3:17 what we mean by the credential aggregation problem, right?

3:20 This is a realistic example of how a remote MCP server would look like,

3:25 that's maybe engineering focused or developer focused, right?

3:28 So it could have GitHub tokens, Slack tokens,

3:32 et cetera that are loaded that the MCP server uses to communicate.

3:39 And before we go further, like I know MCP is a lot,

3:44 it's a open protocol, there's ways to extend it.

3:48 So there's local MCP servers...

3:51 Sorry, local MCPs and CP servers that are hosted remotely.

3:56 I'm not going to talk about the local site today because

3:59 they're run as child processes and they have a different threat model.

4:03 What we're focused on is Zoom modem CP servers deployed as a service

4:08 shared across users or agents running on cloud or hosted infrastructure,

4:13 and that's where this threat model sort of applies.

4:18 So if you think about this, all this credential aggregation,

4:21 the blast radius is pretty high, right?

4:24 Like if you...

4:25 This could be depending on the access control

4:30 and other permissions that are part of these tokens,

4:35 it could be (indistinct) to all GitHub

4:38 perhaps and even sometimes full database access.

4:41 So the blast radius of, you know,

4:44 a memory dump are being able to get these credentials is pretty high.

4:51 So just to sum it up, to make your LLMs and agents useful,

4:55 they need to use MCP to talk to the real world

4:59 and the more the tools you add to make it work for you,

5:03 the larger the blast radius.

5:08 So there are controls that are in place, right?

5:12 There is IAM, Role-Based Access Control, and other controls.

5:18 So we can go each one, one by one and we have IAM and RBAC,

5:24 which assumes the host is trusted again,

5:27 but this does not prevent any memory reads.

5:31 Secrets vault, this is very good in practice.

5:35 It needs to be there,

5:37 and this protects data addressed and the secrets addressed.

5:43 But once they get into the MCP server so that they can be used,

5:47 that's when they get vulnerable.

5:49 And just by the way their work MCP servers do

5:53 have to talk to the external world to be useful.

5:59 So there is external outbound network policies that let

6:02 the MCP servers talk to these external worlds, so there could be exfiltration.

6:10 And then container isolation,

6:12 this is another good practice where you build containers to run these servers.

6:17 But again, if you get access to the host, all these controls sort of go away,

6:24 and we need to remove the assumption just because of the credential

6:30 aggregation and blast radius that we have, that MCP servers.

6:35 So again, the core problem is you could...

6:39 If you, again, root sort of host access, you can inspect the memory,

6:43 extract the secrets, and then we will be able to exfiltrate via CTPS.

6:50 So let's talk about how confidential

6:53 computing can help prevent these attacks, right?

6:55 I'm sure folks who are familiar with confidential

6:59 computing kind of see where this is going.

7:03 So for each TEE property, there is a threat that's closed.

7:07 So the first one which is memory encryption,

7:10 you can dump the memory to try and get the credentials,

7:13 but all you see is SAP text and you can't gain access.

7:19 Remote attestation, think about tampered image.

7:23 If you apply remote attestation and verification the right way,

7:27 even though if it gets deployed normally,

7:32 key wall checks and other checks where you could

7:35 gate the credentials will not be able to pass,

7:41 because the attestation will show that this is

7:44 an image that hasn't been approved.

7:48 Attestation-gated credential delivery,

7:50 like this is what we call a secure key release in most scenarios.

7:56 So any secret that needs to be loaded to the MCP server,

8:00 whether it be baseline credentials that you need to talk

8:06 to a surface versus scoped tokens that agents might send per session,

8:11 all of this can be gated based on the attestation.

8:16 Code integrity, like it can help with supply chain attacks,

8:20 like if there is a malicious dependency that gets into the container build,

8:26 the CPU can measure the anti-measured launch.

8:29 So if the measurements don't match the known good hash,

8:33 then the key release attestation, all of them will fail.

8:36 So this can catch supply chain attacks that could lead to exploitation.

8:41 And the final one, which at least is

8:44 my favorite when it comes to TEEs and confidential computing,

8:51 the measurement becomes sort of the cryptographic identity, right?

8:56 Because the same source code and the build

9:00 process always produce the same measurements.

9:02 I know this could be tricky to get right,

9:05 but this does get to the same measurements.

9:10 And then once you publish the known good measurement,

9:13 any relaying party including the agent orchestrator, control plane, auditor,

9:19 like can verify via remote attestation before connecting,

9:23 and this is the identity at the hardware level that cannot be forced easily.

9:29 So all this gives sort of the right properties

9:35 to close the threat models that we are seeing.

9:38 And I just want to add a bit

9:40 here because when we talk about protecting AI workloads,

9:45 we think about GPUs a lot, and they are very important.

9:49 We need to have the right GPU support.

9:53 I'm glad that we are investing in confidential GPUs.

9:57 But all of this MCPs are not GPU bond workloads,

10:04 these are CPU workloads that can be protected

10:07 with the current CPU technology that we have.

10:10 I know we're getting GPUs, but this is something that we can do beyond the work

10:18 that is already being done on the GPU and the ecosystem around it.

10:25 So one pattern, right?

10:26 This is the same architecture that can be reused to protect MCP servers.

10:32 So we need a hardware TEE.

10:35 This could be AMD SEV-SNPm, Intel TDX, or ARM CCA.

10:39 All this encrypts VM memory in the silicon.

10:42 Computational containers like this fits right in because it

10:46 provides the ability to provide these measurements and use them.

10:51 We need an attestation service to verify

10:54 and validate the hardware codes that the relying party

10:57 can use and also gated key release policies

11:03 that secrets are bound to the attested code measurements.

11:06 So these patterns are supported by the CoCo project,

11:10 the Confidential Container project.

11:13 Our friends at Edgeless have contrast that can do

11:16 this and also hyperscalers like some of the products

11:19 that I work on also support sort of these feature

11:23 sets that can be used to protect the servers.

11:28 So trying to bring all of this together into one concrete slide.

11:34 So as it described, I see MCPs having a two-layer credential model, right?

11:40 So the first model is the baseline cervix accounts, that could be DB_URLs,

11:46 GitHub service tokens, et cetera, and also agent scoped tokens.

11:51 Both of these have different days to get the secrets in to the servers.

11:57 One could be at the boot up time that are really fault or HSM.

12:05 And agents that have the user context or an action

12:09 by the user or credentials provided by a user that are

12:16 agents scoped can be sent to the MCP server after

12:23 validation with attestation similar to what the key walls do.

12:28 So just sort of brings the whole project together.

12:31 We have the means of reducing the blast radius and ensuring

12:36 that we are communicating with a good known MCP server

12:40 that can reduce the credential leakage and harm that comes

12:48 with the segregation while still keeping LLMs and our agent harnesses useful.

12:58 So we have the hardware proofs that, you know,

13:02 this is the right image relying party verify,

13:05 and then we have the credential flows going

13:08 in, and there's several failure modes that can break this chain.

13:13 If it's a modified container image, it can be caught.

13:16 If debug mode is enabled on any of the servers,

13:20 which can make it easy to get these credentials, that can be caught.

13:24 If it's been a while since the attestation happened, it can be caught.

13:29 And the same with the host route that's prevented with this model and approach.

13:38 So we have to be honest, right?

13:41 Confidential computing is a different in-depth mechanism.

13:44 So TEEs are necessary, but not sufficient.

13:46 We have to pair them with prompt injection and which...

13:51 Sorry, prompt injection guarantees that we need to sort of work through.

13:56 Sampling is another attack that I feel is something that isn't too well-known,

14:02 like so it's sort of reverses like usually in the normal workflow,

14:08 the agent or LLM talk to the MCP server,

14:12 but sampling reverses that model where an MCP server can

14:15 ask an LLM to generate text on it on its behalf.

14:18 So reversing the direction of influence,

14:21 I sometimes call it an MCP server social engineering, the LLM.

14:25 There's tool poisoning attacks,

14:26 so all these cannot be prevented by just TEEs alone.

14:30 So all this have to be thought through,

14:33 but we do close the privileged host access and the supply chain attacks,

14:40 that part of the threat model here.

14:43 So this is what we need for some of the full defense.

14:48 And like as I mentioned,

14:50 we need to think beyond just protecting these credentials to secure MCP servers.

14:57 We need to have a good permission design, runtime controls,

15:01 and isolation as we talked about to help prevent any of these attacks,

15:06 credential attacks that happen.

15:08 So I think we need to think through all these and then

15:13 a TEE can definitely reduce the attack surface and the credential leaking.

15:22 And like what to do Monday, like I know folks try to like end with this.

15:27 So map your MCP credential surface,

15:29 try to figure out what secrets your MCP server has access

15:33 to or they audit host access to AI and your workloads,

15:38 and should the MCP capability model,

15:41 including the isolation, that confidential computing provides.

15:45 So I think that's the end of the topic.

15:50 I do have reference implementation,

15:53 which is based on Azure that I can share further here,

15:58 and yeah, we can cut with me for any questions.

16:01 (upbeat music)