What Can Your AI Agents Actually Do? Cedar Analysis for MCP Servers

Presented at MCP Dev Summit Toronto 2026 together with Chris Burns
Sched: https://events.linuxfoundation.org/mcp-dev-summit-toronto/program/schedule/?id=1263742
Recording: TBA

Abstract:
The MCP spec recommends servers not to reinvent the access control wheel. Now the question is: what OSS building block will emerge as the access control foundation of choice for the MCP ecosystem, to avoid fragmentation?

The CNCF project Cedar Policy offers a declarative language and engine for attribute-, relation- and role-based access control policies, making it easier to audit, version, reason about and share policies across applications. ToolHive recognized Cedar's utility and uses it to enforce consistent access control across MCP servers.

Cedar is grounded in mathematical logic, which means you can analyze, compare, and query policies themselves, not just evaluate them. Did your refactored policies change any decisions? Is an allow policy actually dead code, always overridden by a stronger deny? Who can access this resource? What can this agent do in the system? Could an AI agent exfiltrate private data to an external sink? These questions Cedar can answer statically and always correctly (unlike LLMs), across all your policies.

After this talk, the audience knows how Cedar could be used to promote ecosystem-wide consistency, and how ToolHive already uses it in production.

Transcript

1. What Can Your AI Agents Actually Do? Cedar Analysis for MCP Servers Lucas Käldström & Chris Burns @luxas @chris-j-burns MCP Dev Summit 2026
2. Who are we? Lucas Käldström Chris Burns Senior Applied Scientist @ AWS Senior Engineer @ Stacklok CNCF Ambassador Kubernetes contributor Cedar maintainer ToolHive maintainer OSS Contributor
3. Outline 1. MCP auth summary a. 2. Cedar Policy as a lingua franca a. 3. Authorization engine requirements Calculating with permissions using Cedar Analysis Demo: Running and authorizing MCP servers using ToolHive and Cedar a. Mitigating data exfiltration risks using static analysis
4. MCP Auth is Three Questions
5. MCP Auth is Three Questions QUESTION 01  Who is the caller, and how do they prove it? Authentication Identity verification & credential proof
6. Static token QUESTION 01 Who is the caller, and how do they prove it? MCP server host static token client tool1 upstreams tool2 tool3  A shared secret in a header, handed over by a human once. It authenticates a copy of a string rather than a SECURITY CHARACTERISTIC caller.
7. OAuth 2.1 Resource Server QUESTION 01 Who is the caller, and how do they prove it? get token authorization server MCP server host aud: this server client tool1 upstreams tool2 tool3 resource server: validates aud  Validate a token you didn’t issue, bound to your own audience, and reject anything issued for someone SPEC MANDATES else.
8. MCP Auth is Three Questions QUESTION 01  Who is the caller, and how do they prove it? Authentication Identity verification & credential proof
9. MCP Auth is Three Questions QUESTION 01  Who is the caller, and how do they prove it? Authentication Identity verification & credential proof QUESTION 02  Who decides what they may do, and where is that enforced? Authorization Policy enforcement & permission boundaries
10. Only upstream authorizes QUESTION 02 Who decides what they may do, and where is that enforced? host MCP server tool1 client upstreams tool2 tool3  No per-caller, per-tool decision is made, so any authenticated caller gets the server’s full tool surface. NOTE This is where most of the ecosystem sits.
11. Both data path and upstream authorizes QUESTION 02 Who decides what they may do, and where is that enforced? host MCP server tool1 client upstreams tool2 tool3 policy in the data path  Rules written as code in the request flow, in the server or a proxy in front of it. NOTE Maybe ok for one server with three tools, but it becomes painful the moment you scale.
12. Both data path and upstream authorizes QUESTION 02 Who decides what they may do, and where is that enforced? host MCP server tool1 client upstreams tool2 tool3 policy in the data path  MCP SECURITY BEST PRACTICE MCP docs says “do not implement authorization logic by yourself”. CNCF projects can help
13. MCP Auth is Three Questions QUESTION 01  Who is the caller, and how do they prove it? Authentication Identity verification & credential proof QUESTION 02  Who decides what they may do, and where is that enforced? Authorization Policy enforcement & permission boundaries
14. MCP Auth is Three Questions QUESTION 01  Who is the caller, and how do they prove it? Authentication Identity verification & credential proof QUESTION 02 QUESTION 03   Authorization Policy enforcement & permission boundaries Delegation & Identity Upstream propagation & backend access Who decides what they may do, and where is that enforced? What identity reaches the thing behind the server?
15. The server’s own QUESTION 03 What identity reaches the thing behind the server? host MCP server tool1 client service account upstreams tool2 tool3  The upstream sees a service account holding the union of every caller’s permissions. SECURITY CHARACTERISTIC Correct when the action really is the server’s, at the cost of all user attribution.
16. The user’s, freshly issued token QUESTION 03 What identity reaches the thing behind the server? host MCP server tool1 client sub: user act: server upstreams tool2 tool3  A new token from the upstreams own AS, which can name the user as subject and your server as actor. SECURITY CHARACTERISTIC AS has to be willing to play ball.
17. The MCP auth design space MCP server host tool1 upstreams client tool2 tool3 Question 1 Question 2 Question 3 Who is the caller, and how do they prove it? Who decides what they may do, and where is that enforced? What identity reaches the thing behind the server? OAuth 2.1 resource server both data path and upstream the server’s own static token only upstream the user’s, freshly issued token token passthrough
18. Expressive Image by Rawpixel.com
19. Expressive Image by Rawpixel.com Fast
20. Expressive Image by Rawpixel.com Fast Safe
21. Expressive Image by Rawpixel.com Fast Safe Analyzable
22. Correct Expressive Image by Rawpixel.com Fast Safe Analyzable
23. Correct Authorization language and engine, a CNCF project Expressive Image by Rawpixel.com Fast Safe Analyzable
24. Correct Attribute-, Role-, and Relation-based Access Control Expressive Image by Rawpixel.com Authorization language and engine, a CNCF project Fast Safe Analyzable
25. Correct Attribute-, Role-, and Relation-based Access Control Authorization language and engine, a CNCF project Expressive Primary language tenets Image by Rawpixel.com Fast Safe Analyzable
26. Rock-solid: Formally verified in Lean Correct Attribute-, Role-, and Relation-based Access Control Authorization language and engine, a CNCF project Expressive Primary language tenets Image by Rawpixel.com Fast Safe Analyzable
27. Image by Jaroslav Machacek
28. Open Policy Agent OpenFGA Cedar Can P do A on R? P = some principal (user) A = some action R = some resource with object known Image by Jaroslav Machacek
29. Open Policy Agent OpenFGA Cedar Can P do A on R? OPA PE OpenFGA List* Cedar TPE P = some principal (user) A = some action R = some resource with object known What can P do directly? Who can access R? Block bound-to-fail requests fast Image by Jaroslav Machacek
30. Open Policy Agent OpenFGA Cedar Can P do A on R? OPA PE OpenFGA List* Cedar TPE P = some principal (user) A = some action R = some resource with object known What can P do directly? Who can access R? Are two policies equal? Block bound-to-fail requests fast Are policies inconsistent? What can P do indirectly? Cedar Analysis Image by Jaroslav Machacek
31. Cedar Analysis: Answer questions about policies For refactor correctness: “Are two policies equivalent?” old new Powered by automated reasoning, a mathematical logic called SMT
32. Cedar Analysis: Answer questions about policies For refactor correctness: “Are two policies equivalent?” old new For privilege escalation prevention: “Is policy A a subset of policy B?” initial permissions subagent permissions Powered by automated reasoning, a mathematical logic called SMT
33. Cedar Analysis: Answer questions For refactor correctness: “Are two policies equivalent?” old new about policies Find logical inconsistencies: ← Deny shadows allow For privilege escalation prevention: “Is policy A a subset of policy B?” initial permissions subagent permissions Powered by automated reasoning, a mathematical logic called SMT
34. Cedar Analysis: Answer questions For refactor correctness: “Are two policies equivalent?” old new For privilege escalation prevention: “Is policy A a subset of policy B?” initial permissions subagent permissions about policies Find logical inconsistencies: ← Deny shadows allow Simplify policies by finding dead branches: ← Never true Powered by automated reasoning, a mathematical logic called SMT
35. Cedar as a lingua franca for access control? MCP Server A Policies API B Policies Identity Provider C Policies Kubernetes D Policies “who can access PII?” “what can lucas do across all systems?” “are there data exfiltration risks?” See the Typed Partial Evaluation blog post how Cedar can answer the first two questions.
36. Use-case: Reasoning about cross-system privileges If the MCP server’s identity is used in the backend, the user has permissions through two paths. If all permissions are expressed in the same language, we can calculate*: Implicit = UserInMCP AND MCPInUpstream Effective = Direct OR Implicit Direct Upstream User UserInMCP MCP Server MCPInUpstream *or over-approximate
37. Use-case: A calculus for permissions <Permission to get internal data> + <Permission to write data externally> = <Meta-permission called “exfiltrate data”>
38. Use-case: A calculus for permissions Permissions that give access to internal data: Permissions that allow sending data externally: List Kubernetes API objects Write to a GitHub issue Read internal wiki Send email … …
39. Use-case: A calculus for permissions <Permission to get internal data> + <Permission to write data externally> = <Meta-permission called “exfiltrate data”> List Kubernetes API objects + Write to a GitHub issue = “Finding” of data exfiltration List Kubernetes API objects + Send email = “Finding” of data exfiltration Read internal wiki + Write to a GitHub issue = “Finding” of data exfiltration Read internal wiki + Send email = “Finding” of data exfiltration
40. What is ToolHive? A Control Plane for MCP ToolHive provides a secure, unified gateway that connects Model Context Protocol (MCP) clients to local and remote servers. • Unified MCP Hub Bridges diverse clients (Cursor, Claude Code etc) with multiple local and remote servers. • Core Capabilities Built-in Registry for tools, secure Runtime execution and routing Gateway. • Secure Integrations Safely exposes external SaaS APIs (Slack, GitHub, AWS etc) and sensitive Enterprise Data stores. SYSTEM ARCHITECTURE
41. Demo Architecture Kubernetes Cluster Environment Clients / Users ToolHive vMCP Terminal support-bot @example.com ••• Kubernetes MCP GitHub MCP Internal K8s API Proxy External Integration GitHub External Platform user-n@ example.com Dex IdP @example.com Authentication Provider Cedar Policy Engine
42. Demo Policies Terminal images generated with carbon.now.sh
43. Demo https://github.com/ChrisJBurns/toolhive-cedar-demo Demo showing ToolHive, Cedar, and cedar-woodpecker in action https://github.com/luxas/cedar-woodpecker Experimental “permissions calculus” proof-of-concept built on top of Cedar Analysis
44. Unwanted implicit permission found statically! Legend: k8s GH Complete permission space Allow policy
45. Let’s bound support-bot’s permissions Legend: k8s GH Complete permission space Allow policy Deny policy GH woodpecker confirms no escalations are possible 🎉
46. Takeaways 1. MCP servers should use a generic engine for access control a. Cedar, Open Policy Agent and OpenFGA are all good options 2. Cedar offers powerful policy querying and analysis features a. Ideally, policies from multiple systems can be centrally reasoned about 3. We showed a proof-of-concept of “calculating with permissions” a. We could statically identify a data exfiltration risk and later prove the fix
47. Let’s continue the discussion! Join Cedar: github.com/cedar-policy Join CNCF Slack: slack.cncf.io Lucas Käldström (LinkedIn, GitHub, SpeakerDeck, CNCF Slack) Chris Burns (LinkedIn, GitHub)