Repository navigation
Example: Semaprax decision service behind ToolHive validating webhooks #6741
Description
Activity
Thanks for the proposal, @wsdt, and for thinking about how Cedar and the validating webhooks could work together on argument-level decisions.
We have decided not to add an example tied to a specific third-party decision service. We would rather keep the examples in this repo vendor-neutral, and we do not want to take on maintaining an integration with an external project.
A generic validating-webhook example would be welcome, though: one that shows a webhook receiving the post-mutation tools/call request, returning allow or deny, and failing closed when the webhook is unavailable. If you would like to contribute that, please open a new issue or a draft PR describing the scope, and we can take a look. The Semaprax integration itself would be a good fit for your own repo, and you are welcome to link to it from there.
Thanks again for taking the time to write this up. Closing this one out.
Motivation
ToolHive already has Cedar authorization and validating webhooks. A useful integration would show how to combine them when the final
tools/callarguments need a stateful, typed decision: Cedar still handles principal/resource grants, while an optional Semaprax decision service evaluates a narrow operation such astransfer(amount, destination)against task state before the MCP server sees it.Proposal
Add a small example configuration and test using ToolHive's existing validating-webhook middleware. The example should send the post-mutation MCP request to the external Semaprax adapter, map allow/deny to ToolHive's webhook response, and fail closed when the decision service is unavailable. It should explicitly identify which identity fields came from ToolHive authentication and which fields are client-supplied. No replacement of Cedar or default dependency is proposed.
Acceptance
An allowed call reaches the upstream tool once. A denied or malformed call never reaches it, with a clear audit outcome. The test should include a mutating webhook so the policy evaluates the bytes actually dispatched; #6133 explains why that ordering matters.
ToolHive middleware: https://github.com/stacklok/toolhive/blob/main/docs/arch/02-core-concepts.md
Semaprax: https://github.com/wavect/semaprax