Reflections from my OC3 2026 talk on securing the Model Context Protocol layer with Trusted Execution Environments.
I gave a talk at OC3 2026 about a problem that’s been bothering me for a while: most MCP server deployments have a serious trust-boundary flaw, and most teams don’t realize it yet.
MCP — Anthropic’s Model Context Protocol — is quickly becoming a common interface between AI agents and the outside world. It’s how your LLM searches GitHub, queries databases, sends Slack messages, creates Jira tickets, and interacts with the rest of your environment. Adoption is accelerating across agent frameworks and tool ecosystems. That’s exactly what makes this urgent.
The credential aggregation problem
Here’s what a typical remote MCP server deployment looks like:
tools:
github_search_issues:
env: GITHUB_TOKEN=ghp_xxxx
query_database:
env: DB_URL=postgres://u:pass@host/db
send_slack_message:
env: SLACK_TOKEN=xoxb-xxxx
create_jira_ticket:
env: JIRA_KEY=ATATT3x...
read_s3_objects:
env: AWS_SECRET_ACCESS_KEY=wJal...
Five tools. Five credentials. One process. Every secret sits in the same address space for the lifetime of the server. The more capable your agent becomes — the more tools you add — the larger the blast radius of a single compromise.
This isn’t a contrived example. A common remote MCP deployment pattern is multiple tools, one process, and all associated credentials materialized in memory. The exact framework varies. The trust problem does not.
Your existing controls don’t cover this
The natural response is: we already have IAM, a secrets vault, and network policies.
Those controls matter. They just don’t solve this specific problem.
IAM / RBAC assumes the host OS is the trust boundary. But a privileged host operator can read /proc/<pid>/environ and recover environment variables directly. IAM never fires because IAM authorizes API calls, not memory reads.
Secrets vaults protect secrets at rest. But the MCP server still decrypts them into RAM to make API calls. At that moment, the vault’s guarantee ends. A privileged host operator can still inspect secrets once they are materialized in process memory.
Container isolation — namespaces and cgroups — helps isolate containers from each other. But it does not defend against a privileged host operator. nsenter bypasses those boundaries by design.
Network policies help with egress filtering, and you should absolutely have them. But the attacker who reads credentials from host-side process memory already has what they need. They don’t have to exfiltrate through the container’s network stack. They can take those credentials to another machine and use them directly.
The container firewall is protecting an empty barn.
Every one of these controls shares the same assumption: the host OS is trusted. Remove that assumption and you need hardware-enforced isolation.
TEEs close the infrastructure gap
Trusted Execution Environments — AMD SEV-SNP, Intel TDX, ARM CCA — give you a different trust model. Instead of trusting the host OS and hypervisor to behave, you isolate sensitive memory using hardware-backed protection.
Root on the host reads /proc/<pid>/mem and gets ciphertext. The memory encryption key is managed by the CPU’s secure processor. The host OS, hypervisor, and cloud admin do not get plaintext access.
For MCP, the important properties are not just “memory encryption” in the abstract. It’s the combination of four things:
Memory encryption blocks host-level plaintext access to secrets in use. This is the direct defense against credential extraction from a privileged host.
Remote attestation lets a relying party verify what code is running before trusting it. If the measured image changes, attestation fails and secrets should not be released.
Code integrity via measurement lets you detect unauthorized changes to the image or startup path before secrets are provisioned. If a dependency, container image, or launch path changes, the measurement changes too.
Measurement as cryptographic identity is the property I find most interesting for MCP specifically. Today, MCP servers don’t have a strong, verifiable runtime identity. An agent connecting over HTTP can authenticate the endpoint, but not the exact code running behind it. With TEEs, the measurement becomes a deterministic, hardware-backed identity that can be verified via attestation before the first tool call.
In a practical deployment, the flow looks like this: the MCP server starts inside a TEE, presents an attestation quote, the client or secret broker verifies the quote against an allow-list, and only then are baseline credentials or agent-scoped tokens released.
One caveat matters: TEEs reduce trust in the host OS and hypervisor. They do not magically make vulnerable or malicious code inside the trusted boundary safe. They solve the infrastructure trust problem, not every application security problem.
And here’s the practical point that often gets lost: MCP servers are mostly CPU workloads. They don’t run inference. They don’t need GPUs. This is deployable on production confidential computing infrastructure available on modern AMD EPYC and Intel Xeon platforms, subject to cloud and platform support.
The two-layer credential model
When I first started thinking about this, I assumed the architecture was simple: put the MCP server in a TEE, let it pull secrets from a key vault via attestation, done.
That model works. It’s just not realistic enough.
In practice, MCP servers usually need two kinds of credentials that arrive through different paths.
Layer 1 — Baseline service accounts. These are the infrastructure credentials the server needs to function at all: a database connection string, a GitHub service account token, a webhook URL. They’re provisioned at deployment time through the standard attestation-to-key-vault flow. The TEE starts, generates a hardware quote, the attestation service validates it, and the key vault releases the secrets. These credentials live in TEE-protected memory for the server’s lifetime.
Layer 2 — Agent-sent scoped tokens. These are user-context credentials that the agent sends per session or per call. A user’s OAuth token so the tool can access their specific repos. An STS credential scoped to a particular S3 prefix. A read-only Jira token for a single project. The agent verifies the MCP server’s attestation against an expected measurement or signer policy first, then sends the tokens. They’re short-lived and scoped.
This two-layer model is a more honest description of how systems actually work. The MCP server has a baseline identity and baseline infrastructure credentials. The agent layers on user-specific access, gated by attestation. The TEE protects both layers from host-level extraction.
What TEEs don’t solve
It’s important to stay disciplined about the threat model.
TEEs close the infrastructure gap: the privileged host access problem. MCP still has application-layer threats that hardware isolation does not address.
Prompt injection: an attacker embeds instructions in tool output to steer the agent’s next action. That requires application-layer defenses like input validation, output sandboxing, and intent verification.
Sampling attacks: the MCP server asks the LLM to generate text on its behalf, reversing the direction of influence. Sampling should be off by default. If you need it, it should never be able to trigger writes without explicit confirmation.
Tool poisoning: a malicious tool definition causes the agent to exfiltrate data through what looks like legitimate usage. That requires signed tool registries, allow-lists, and stronger policy controls.
Full defense requires both layers. TEEs handle the infrastructure threat. Your application architecture handles the rest.
Ship both.
The capability model still comes first
I’ve written the broader argument already in MCP is a Capability System (Treat It Like One), so I won’t repeat the whole checklist here.
The short version is simple: MCP should be treated as a capability system, not just a tool layer.
That means three things:
Permission design: treat every MCP server as a third-party integration. Default-deny capabilities. Separate read tools from write tools. Enforce authorization at the tool boundary, not the LLM.
Runtime controls: require user confirmation for high-risk actions. Log every tool call as security telemetry. Add quotas and circuit breakers.
Isolation: use process or container isolation to reduce blast radius, then add TEEs when you need protection against privileged host access.
This sequencing matters.
Permission design and runtime controls are things you can implement this week with no infrastructure changes. They reduce blast radius immediately. TEEs solve the deeper infrastructure problem: removing the host OS and hypervisor from the secrets trust boundary.
So the right answer is not capability model or TEEs.
It’s capability model first, then TEEs to close the remaining trust gap.
What’s next
There are four areas where I think the confidential computing community can push the boundary from here:
Multi-party attestation for tool chains. In agentic AI, a request may traverse multiple MCP servers. Each one can attest independently today. There’s still no standard way to verify the full chain of custody.
Dynamic capability delegation. LLMs will increasingly grant sub-agents scoped, time-limited tool access. How should a TEE enforce capability tokens issued by a model rather than directly by a human?
Attestation-aware MCP transport. MCP uses stdio and SSE today with no built-in runtime identity check in the handshake. Embedding measurements into the connection flow would let clients verify server identity at connect time.
Confidential observability. Sealed audit logs are tamper-resistant but opaque to SOC teams. We need attested, redacted telemetry streams that are operationally useful without leaking secrets.
These are areas where I think the ecosystem should push next.
Three things to do Monday
If you take nothing else from this:
- Map your MCP credential surface. List every secret your MCP server holds. Most teams are surprised by how long this list gets.
- Audit privileged host access. The people or systems with host-level access to your AI workloads are part of your real threat model.
- Ship the capability model. Default-deny, scoped tokens, and confirmation gates for writes are not optional hygiene anymore.
Then let the model be smart inside the box.
I’m a Senior Product Manager on the Azure Confidential Computing team at Microsoft. The views here are my own. If you’re working on MCP security or confidential computing for AI workloads, I’d love to connect — reach out on LinkedIn or check out the mcp-tee-sample reference implementation.