Optimizer should be transparent to Cedar authorization policies

[jerm-dro]

As a VirtualMCP server operator, I don't want to rewrite all my cedar policies when I enable/disable the optimizer.

Problem

When Cedar authorization policies are enabled on a vMCP server, enabling the optimizer silently breaks existing Cedar policies.

The optimizer replaces all backend tools with find_tool and call_tool meta-tools. Cedar's response filter evaluates each tool in tools/list against the user's policies, but those policies reference real backend tool names (e.g., Tool::"weather"). Since neither Tool::"find_tool" nor Tool::"call_tool" matches any permit policy, default-deny filters both out — tools/list returns zero tools with no error.

There is a workaround today: operators can write Cedar policies that explicitly permit the meta-tools and use argument inspection (context.arg_tool_name) to restrict which backend tools can be invoked through call_tool. But this requires operators to know about the optimizer's internal tool names, which defeats the purpose of the optimizer being a transparent performance layer.

Expected behavior

Enabling the optimizer should not require rewriting Cedar authorization policies. An operator's existing policy like:

permit(principal, action == Action::"call_tool", resource == Tool::"weather");

should continue to work regardless of whether the optimizer is enabled.

Possible approaches

Here be dragons: The reason this problem exists in the first place is that cedar policies are applied to the tools/list response at the middleware layer. No other system within vMCP is aware of what tools the user is authorized to use. The ideal fix requires sharing this information with the other systems. That's easier said than done.

Test coverage

Integration tests demonstrating the incompatibility and the workaround are in:

• pkg/vmcp/server/session_management_integration_test.go — TestIntegration_OptimizerWithCedarAuthz

Generated with Claude Code