toolhive VS cedar

With the new network isolation features in ToolHive, you don’t have to trust. You can verify – and enforce.

GitHub

At Stacklok, we created ToolHive because we saw a gap in running MCP servers easily but also securely. As security engineers, we knew there had to be a better way.

This looks interesting, but anytime security is offloaded to an LLM I am extremely skeptical. IMO the right way to do this is to enforce permissions explicitly through a AuthZ policy. Something like what Toolhive [0] is doing is the right way I think.

All MCP comms from client to server go through an SSE proxy which has AuthN and AuthZ enabled. You can create custom policies for AuthZ using Cedar [1].

[0] https://github.com/stacklok/toolhive, https://github.com/stacklok/toolhive/blob/main/docs/authz.md

Building on our earlier discussion about enterprises needing dedicated hosting for MCP servers and ToolHive's Kubernetes-based solution, we're excited to announce our new Kubernetes Operator for ToolHive. This specialised tool streamlines the secure deployment of MCP servers to Kubernetes environments for enterprise and engineers.

For more details, check out the README .

The team at Stacklok, empowered by our CEO, Craig McLuckie (and co-creator of Kubernetes), recently released ToolHive, an open source project that offers a convenient way to run MCP servers with familiar technologies with authentication, authorization and network isolation. Let’s take a closer look at how ToolHive and Kubernetes come together to support MCP in an enterprise environment.

As more teams start deploying MCP servers to power tool-calling agents, one question comes up fast: how do you control who can call what? It’s not just about verifying identity, it’s about enforcing the right permissions, without bloating every server with bespoke auth logic. ToolHive was built to solve exactly this problem. It separates authentication from authorization, integrates cleanly with existing identity providers, and uses Amazon’s Cedar policy language to define clear, auditable access rules. The result is a simple but powerful way to lock down tool access without embedding auth logic into every server you run.

We are excited about the potential of Model Context Protocol (MCP) servers and inspired to make it more consistent to set up, easier to configure and overall secure. So, we're releasing ToolHive as an open-source project that uses existing technology (e.g. Docker and Kubernetes) for better packaging, security utilities, and more. Let's build on MCP together!

The heart of ToolHive’s authorization is the Cedar policy language. Cedar is a flexible, expressive, and formally verified language for access control, supporting both role-based and attribute-based rules. ToolHive leverages Cedar to define who can do what in terms of MCP operations.

Amazon Verified Permissions (AVP) uses Cedar, a purpose-built, policy-as-code language designed for fine-grained authorization. Cedar enables us to define and enforce access control policies that dictate who can perform what actions on which resources.

Amazon Verified Permissions is a fully managed, scalable authorization service designed for custom applications. It uses the Cedar policy language to define and enforce fine-grained permissions, allowing developers to externalize authorization logic and centralize policy management.

Cedar, the new language by AWS that's currently used by Verified Access, is looking good; https://www.cedarpolicy.com

Amazon has open sourced their policy engine https://github.com/cedar-policy/cedar

Curious what folks think about this versus cedar (https://www.cedarpolicy.com/), the open source policy engine behind aws verified permissions.