Confidential Computing Summit 2026 ยท San Francisco
Trust Is the Next Bottleneck
Why the Agentic Economy Needs Confidential Computing
Pawan KhandavilliSenior Product Manager ยท Azure Confidential ComputingJune 23-24, 2026 ยท The Mint, San Francisco
v2 ยท updated 2026-06-14
Since the start of this year. Five numbers. One architecture failure.
770KAI agents compromised simultaneously via a single database vulnerabilityMoltbook breach ยท Wiz ยท Feb 2026
195Mcitizen records stolen by one attacker using Claude Code + GPT-4.1Mexican government breach ยท SOCRadar ยท 2026
150M+downloads across a poisoned MCP supply chain, 10 CVEs, 9/11 registriesOX Security ยท April 15, 2026
1 charin an HTTP Host header exposing clinical databases, email inboxes, and SSH access to industrial devicesBadHost ยท CVE-2026-48710 ยท X41 D-Sec
โฌ0.01one bank transfer memo hijacking a financial AI agentBlue41 ยท Bunq ยท Jun 2026
None of these agents could prove (cryptographically, verifiably, to anyone)
who they were, what code they were running, or whether they'd been tampered with.
Act 1 ยท The Third Wave
I've seen this movie twice before
Wave
Year
The Trust Problem
The Hardware Fix
Outcome
๐ณ Payments
2014
Magstripe cards cloned at scale
EMV chip + Secure Element attestation
$2T contactless payments in 2025
โ๏ธ Cloud
2018
"Trust our hyperscaler" promises
Intel SGX / TDX, AMD SEV-SNP โ TEEs
75% enterprise CC adoption (IDC 2025)
๐ค Agents
NOW
OAuth tokens for 10K decisions/min
Attested agent identity, this talk
$236B market by 2034
"Visa is putting verifiable agent identity into its payment network. It can prove who an agent claims to be, but not what code is running. Payments is reaching for a hardware root of trust, and this room already built it."
June 11: Visa connected its payment network to ChatGPT. Reddit's top reaction (4,503 upvotes): "First person to trick the chatbot is about to make bank."
Act 2 ยท Payments Convergence
Payments is building agent trust right now
๐ต Visa
Trusted Agent Protocol
Signed agent-identity headers at the transport layer. Verifiable identity per request, not per session.
verifiable identity
๐ Mastercard
Agent Pay
Tokenized agent identities. Dynamic credentials bound to authorized intent.
tokenized identity
๐ข Google
AP2 (Agent Payments Protocol)
Verifiable credentials with signed mandates contributed to FIDO Alliance.
signed mandates
๐ FIDO Alliance
Agentic Authentication TWG
Chartered April 27โ28, 2026. Three workstreams: Verifiable User Instructions, Agent Auth, Trusted Delegation for Commerce.
standards forming now
โ ๏ธ Every protocol demands verifiable agent identity, but none specify a hardware root of trust. That's the missing layer. That's us.
Act 2 ยท The Proof Gap
The approval path has no hardware witness
Blue41 / Bunq (Jun 10): A โฌ0.01 transfer with prompt injection in the memo field hijacked the banking AI agent. Legitimate context becomes attack vector with no attestation boundary.
Act 3 ยท The NSA Agrees
The NSA got MCP right, and missed the deeper problem
"Five weeks before this talk, the NSA's AI Security Center published its first official MCP threat model. 17 pages, the most careful security treatment of MCP to date. It calls for cryptographic agent identity and verifiable logs, and stops short of a hardware root of trust."
NSA AI Security Center Advisory, May 2026
"The NSA document misses the real problem. Securing the API endpoints doesn't help when the attacker's actual leverage is poisoning the context that flows through those endpoints."
Data Science Collective, May 2026 (Medium)
"MCP Is Dead?", Quandri engineering blog (May 29, HN 400 pts, 410 comments): "Tool definitions alone consume 10.5% of Claude's context window. The architecture is insufficient."
"When Agent A receives a token, delegates to Agent B, and Agent B spawns Agent C, each hop either reuses the original token (overprivileged) or has no token at all (untracked)."
O'Reilly Radar, May 26, 2026
Act 3 ยท The Governance Gap
Everyone building agent security. Nobody on hardware.
โ Frameworks converging
OWASP Agentic Top 10: Goal Hijack, Tool Misuse, Identity Abuse. Published May 2026.
Microsoft Agent Governance Toolkit: open-source, maps all 10 OWASP risks. May 27, 2026.
NSA AI Security Center: MCP threat model. May 2026.
NIST AI RMF: Agentic AI agent standards initiative. Feb 2026.
WorkOS auth.md: Agent registration protocol. May 25, 2026.
Stanford CS336 CLAUDE.md: Agent safety guidelines adopted in curricula.
โ ๏ธ All stop at software trust
Okta for AI Agents: OAuth/OIDC identity. GA April 30. No hardware attestation.
Cequence AI Gateway: Runtime privilege scoping. No hardware root.
BeyondTrust PathfinderAI: PAM + MCP server. No TEE binding.
ServiceNow: Agent risk governance. No hardware attestation.
CSA MAESTRO: 7-layer threat taxonomy. No hardware layer defined.
AI Agent runs amok in Fedora (HN 549 pts, Jun 11), identity never verified.
๐ฏ "Everyone is building agent security. Nobody is building it on hardware."
Act 3 ยท Layer Analysis
These controls are necessary, not sufficient
โ advance to reveal
Control
What it proves
What it can't prove
Status
OAuth 2.0 / OIDC
Who authorized the action
Which binary is executing it
Necessary
IAM Roles / RBAC
What permissions are granted
Whether runtime is uncompromised
Necessary
API Guardrails
Input/output policy compliance
Whether the model itself was tampered
Necessary
Audit Logs
What actions were recorded
Whether logs were tampered with
Necessary
Hardware Attestation (TEE)
Code + runtime integrity, cryptographically
Application-layer policy (still needs the above)
Foundation
"Application-layer agent identity delivers critical capabilities, but cannot independently provide cryptographic assurance that an agent is running expected code in an untampered environment. The goal is composition, not competition."
Act 3 ยท The Gap
Four gaps nobody has closed
1
Attested Agent Identity
No standard for TEE-backed proof of what agent code is running. SPIFFE works. TEE-binding doesn't exist at scale.
2
MCP + Attestation Integration
Protocol-level verification of tool server identity. The MCP spec makes server identity optional and software-only. Nothing in the protocol binds tool invocation to hardware attestation.
3
Attested Delegation Chain
RFC 8693 token exchange at each hop, but with TEE measurements. When Agent A โ B โ C, each hop needs hardware proof.
4
Cross-Cloud Agent Trust
Federated attestation for multi-cloud agent workflows. No standard. Azure TDX โ GCP TDX โ NVIDIA CC = no chain of trust today.
MCP spec ships final release July 28, five weeks after this talk. Still no attestation layer. The window to influence it is right now.
Act 4 ยท The Convergence
Three teams. Same week. Same architecture.
๐ Uber Engineering
May 21, 2026
SPIRE-issued workload identities per agent
Per-hop token exchange via RFC 8693
Provenance: engineer โ agent โ action
Roadmap: verifiable provenance in audit logs
Missing: SPIRE inside a TEE. Identity tokens carry delegation provenance, but not hardware proof of issuer integrity.
๐ attestable-mcp-server
May 22, 2026 ยท arXiv:2605.24248
Offline-signed clearance assertions for MCP tool servers
Deny-by-default per-server tool allowlists
--enclaved mode: deny without attestation
Tamper-evident audit log, normative RFC 2119 spec
Status: Open source. Enforcement mode exists. Waiting for this room to adopt it.
๐ 1Password ยท Keycard
May 21, 2026
Runtime credential delegation via attestation
No long-lived API keys. No credentials on disk.
Verifiable agent identity at runtime via attestation
Session-scoped, RFC 8693 per-hop exchange
Signal: Two separate vendors, same week, same trust anchor. 1Password for agent credential management, Keycard for runtime attestation. Not OAuth. Not API keys.
Three independent teams. Different companies. Different countries. Same week. Same answer: attestation.
Intel TDX / AMD SEV-SNP / ARM CCA / NVIDIA CCE (H100 / Blackwell)
โ Production
1
Hardware Root of Trust
On-die RoT, remote attestation, IMY GDPR Article 32 ruling | Sweden: "shifting from promises to verifiable proof"
โ Proven
Confidential GPUs protect the model. Layers 3-6 protect the agent.
Next slide: every layer applied to a live payment flow โ
Act 4 ยท Production Example
E2E payments agent on Confidential ACI
This architecture defeats the Blue41/Bunq attack: the context path is attested and sealed, a memo field cannot become an agent instruction because the context channel itself has a hardware witness.
Side-channel attacks on SGX, Spectre, Foreshadow. Patch: microcode, enclave hardening.
Vendor dependencies, different attestation formats per cloud.
Performance overhead, measurable on crypto-heavy workloads.
โ Why hardware trust is still better
When a TEE breaks, the trust model is explicit: a measurement, a CVE, a patch, and you re-attest. Painful, but bounded.
When OAuth breaks, the trust model is implicit: nothing verified the code behind the token, so the first signal is the breach.
Side-channel attacks get mitigated. Prompt injection has no patch, because the trust model itself is the bug.
๐ก "The asymmetry isn't that hardware never breaks. It's that hardware trust is explicit: when it breaks, there's a measurement, a CVE, and a patch. Software trust is implicit: when it breaks, the first signal is the breach."
Act 5 ยท Urgency
The market is moving with or without us
Aug 2, 2026EU AI Act high-risk requirements become enforceable, 7 weeks from today. Technology-neutral, but requires verifiable technical assurances. Hardware attestation is the strongest foundation available. Deadline
Jul 28, 2026MCP spec ships final release, 5 weeks from today. Still no attestation layer in any SEP. The window to influence it is closing. Closing window
May 25, 2026Sweden IMY ruled TEEs satisfy GDPR Article 32: "shifting the basis of trust from promises to verifiable proof." First regulatory recognition of TEE as compliance anchor. Legal precedent
WorkOS / Uber 1PasswordWorkOS shipped auth.md. Uber shipped agent identity (SPIFFE + RFC 8693). 1Password shipped attestation delegation. The market is converging on attested identity, waiting for the hardware layer.
Jun 14, 2026pkhandavilli/agent-governance-toolkit: provider-neutral handshake attestation PR open. Building in public. 9 days before this talk.
๐ Apple shipped PCC on Google Cloud (Intel TDX + NVIDIA CC + Titan), details expected at THIS summit
Act 5 ยท The Call
What this room should build
1
If you build agents: demand attested execution
Stop shipping credentials in environment variables. Stop using long-lived API keys for autonomous agents. Uber, 1Password, and a team of grad students with an arXiv paper figured this out in May. Your agents should be at least as secure as an Uber microservice.
Agent builders
2
If you build infrastructure: connect TEE attestation to agent identity
SPIFFE works. RFC 8693 works. attestable-mcp-server works. The primitives exist. The integration doesn't. Run SPIRE inside a TDX or SEV-SNP boundary. Issue X.509 SVIDs with TEE measurements attached. That's the missing layer.
Infra builders
3
If you set standards: hardware attestation belongs in every framework
OWASP Agentic Top 10. Microsoft AGT. NIST. ISO. CSA. CCC. Every framework is defining agent security vocabulary, none include hardware attestation as a requirement. This community needs to show up in those frameworks. Not as nice-to-have. As the foundation.
Standards bodies
Confidential computing for agent governance: I've opened a provider-neutral attestation proposal against the Agent Governance Toolkit: hardware attestation, TEE-backed identity, and sealed credential storage as shared primitives for the governance layer. This has to be a community effort. The attestation layer should be a shared primitive, not a proprietary add-on. If you maintain a framework, let's build it together. PR open: github.com/pkhandavilli/agent-governance-toolkit/pull/1
I've watched two trust revolutions.
Wave 1
Payments.
Wave 2
Cloud.
Wave 3
Agents.
Both followed the same arc: innovation first, trust later, hardware eventually.
The agentic economy is the third wave, and it's moving faster than either of them.
The difference this time? We're not late. The standards are being written right now. The builders are publishing right now. The regulators are ruling right now.
The only question is whether the trust layer ships before or after the breach that makes 770,000 look like a rounding error.
This room has built every confidential computing primitive that exists.
Let's make sure the agentic economy is built on top of them, not beside them.
All sources & evidence: github.com/pkhandavilli/ccs2026-trust-bottleneck
Appendix ยท For Q&A
What attestation does and doesn't stop
✅ Attestation proves
Who the agent is, that the code is unmodified, and that it runs in a genuine TEE on a hardware root of trust.
identity + integrity
⚠️ It does not stop
A legitimate, attested agent that gets prompt-injected or socially engineered into asking for the wrong thing.
the trick still works
🔒 The closing layer
Deterministic policy enforced in the TEE and bound to attested identity. A tricked agent still can't exceed its scope.
layer 5: policy
Attestation answers who and what. Deterministic policy answers what it's allowed to do. You need both: identity alone doesn't survive a prompt injection.
Appendix ยท For Q&A
Interoperability is the gap every platform shares
🟫 AWS Nitro Enclaves
Isolated enclave, no persistent storage or interactive access, KMS attestation to release keys.
isolation, AWS-scoped
🔵 GCP Confidential Space
Confidential VM plus workload identity; attestation tokens gate secret release.
workload identity, GCP-scoped
🟩 Azure C-ACI + 6-layer stack
SEV-SNP confidential containers, MAA attestation, customer-verifiable measurements.
verifiable measurements, Azure-scoped
Each solves isolation and attestation inside its own cloud, and each does it well. What is missing is interoperability: a portable way to bind attestation to agent identity that holds across providers, Azure included. That cross-cloud handshake is the open work the industry has to do together.
Appendix ยท For Q&A
We don't need new standards. We need to extend them.
Standard (exists today)
What it gives
The CC extension
IETF RATS RFC 9334 · EAT
Attestation evidence and a claims format
Carry TEE measurements as verifiable claims
SPIFFE / SPIRE CNCF · SVID
Portable workload identity
Gate SVID issuance on attestation; embed the measurement
OAuth 2.0 RFC 8693 · DPoP 9449
Delegated, proof-of-possession tokens
Bind the token to an attested TEE key, not a bearer secret
IETF WIMSE working group
Workload identity across systems
The provider-neutral agent-identity root
MCP attestable-mcp-server
Agent and tool protocol
Attest server and tool identity before granting trust
The framework layer (OWASP Agentic, NIST, CSA, CCC) should name hardware attestation as a requirement, not a nice-to-have. The point: extend what exists, don't reinvent it.
Appendix ยท For Q&A
Why not just OAuth scopes?
🎫 OAuth bearer token
Whoever holds it is the agent. Not bound to code or hardware. Coarse, static scopes. A stolen token is full impersonation.
the Uber + Claude Code failure mode
🔏 Attested agent identity
Bound to the TEE measurement and hardware root. Proves unmodified code. Short-lived, per request. A copied token can't move the hardware root.
theft doesn't transfer trust
OAuth answers "is this token valid?" Attestation answers "is this the right agent, running the right code, right now?" Scopes are necessary, not sufficient.
Appendix ยท For Q&A
Building in public: the attestation handshake
1
Agent presents evidence
On startup the agent sends its TEE attestation (SEV-SNP or TDX measurement) to the governance layer, not just a bearer token.
2
Governance verifies, then issues identity
The measurement is checked against policy before any agent identity or credential is granted. Provider-neutral: the verifier doesn't care which cloud.
3
Credentials sealed to the TEE
Secrets release only to the attested boundary, so a copied credential is useless outside it.
This is a proposal in public review, not a shipped feature: I opened a provider-neutral attestation PR against the open-source Agent Governance Toolkit. The attestation layer should be a shared primitive. github.com/pkhandavilli/agent-governance-toolkit/pull/1