sbproxy: one policy engine in front of three kinds of traffic

Three traffic types, one request pipeline

The framing sentence is the whole product in one line. sbproxy is a single Rust binary that puts one policy engine in front of three kinds of traffic: HTTP APIs, AI model calls across 70 native providers reaching more than 200 models through one OpenAI-compatible endpoint, and MCP or agent-to-agent tool calls. All three run through the same request pipeline, so a rate limit, a guardrail, a budget cap and an audit record behave the same way regardless of which traffic type triggered them. That is the design argument, because the alternative is three proxies with three policy languages and three audit formats. Every feature in the repository ships under Apache-2.0, and the repository publishes a container image alongside the release binaries.

Five policy engines run in-process, with no sidecar

Extension without a sidecar is the first reason given for the project. Five engines run inside the same process as the request pipeline: CEL for one-line gates, Rego through the Regorus interpreter for teams migrating policies they already wrote for OPA, Lua and JavaScript for stateful transforms, and sandboxed WebAssembly for anything the first four cannot express. The practical consequence is stated plainly: there is no OPA server to run alongside the proxy and no separate plugin daemon. For a team that already has Rego, that means the policy work does not have to be rewritten, and the operational surface stays a single process to supervise. A hook is one of four kinds rather than an open plugin API: an action, an auth hook, a policy hook or a transform. The repository also documents a documentation index grouped by first run, traffic type, operations and reference, and an examples directory holding complete configurations, so the fastest way to judge the gateway is to read a configuration rather than the prose.

Extension bundles are pinned by commit and content digest

A bundle adds a hook of one of four kinds, an action, an auth hook, a policy hook or a transform, and it comes either from a local directory or from a git checkout. The pinning is the part worth reading twice: the checkout is pinned to a commit SHA plus a content digest, where the digest covers the entry file by default and the whole bundle on request, and signature verification is optional. Bundles are hot-reloaded with no rebuild. So the supply chain question for a plugin is answered at the same level as for a container image, and the default of hashing only the entry file is the trade you would want to widen for a bundle you did not write.

The audit trail is hash-chained and signed per channel

The audit story is described as tamper-evident rather than merely logged. Security, config, key-mutation and admin-action events each append to their own hash-chained, Ed25519-signed log, and you opt each channel in. Verification is a command: sbproxy audit verify re-derives the chain from genesis and catches a tampered entry. Separately, guardrail and policy decisions publish as typed records to your SIEM, which is the split that matters operationally, since the signed chain answers who changed what while the SIEM stream answers what the policies decided on live traffic.

Security coverage is graded, and one purpose is still unreachable

The AI gateway security coverage document rates every category in the OWASP LLM Top 10 for 2026 as enforced, enforced with named limits, or out of gateway scope, and adds eight gateway-layer risks that the list itself does not cover. Two implementation notes go with it: budgets deny at the cap across seven scopes instead of logging past the cap, and every outbound destination is tracked across fourteen traffic purposes behind a default-deny allowlist. Then the admission: engine artifact downloads are the one purpose the allowlist still cannot reach. Grading coverage this way, and naming the gap in the same document, is the most useful thing in the repository for anyone deciding whether the gateway is enough.

The MCP gateway assumes the upstream can change underneath you

MCP support is framed as being built for an upstream you do not control. Tool contracts are pinned by digest in a committed lockfile and re-checked on every catalog refresh. If a definition moved, a compatibility oracle grades it and either reports or blocks it. A rename is caught by re-digesting the old name. And a version bump that understates a breaking change fails a linter check before it ships. Tool access is scoped per caller with a default-deny posture. That combination, lockfile plus oracle plus linter, is the part you would want if you are federating tools from a third-party server rather than your own.

Local models share the keys, budgets and ledger of hosted ones

The same binary serves local models. sbproxy run starts a managed local model and hands it the same keys, budgets and usage ledger that govern requests routed to a hosted provider, so switching a workload from a hosted model to your own GPUs does not move it out of policy. A semantic cache serves near-duplicate prompts from an embedding index, and it can run fully local either with the sidecar or with an in-process source. Metering is designed to be checkable by the other side: metered requests cut Ed25519-signed, hash-chained receipts that a buyer can re-derive and verify without trusting your dashboard. The same binary also runs the managed model directly, which is why a self-hosted deployment is described as the same product rather than a fallback: same keys, same budgets, same ledger, same audit channel.

Install paths, an example loop, and a workspace that skips its Kubernetes crates

The install path is a script that writes to your local bin directory, and the version check is the last line of it:

curl -fsSL https://download.sbproxy.dev | sh
export PATH="$HOME/.local/bin:$PATH"
sbproxy --version

Release archives exist for Linux on amd64 and arm64 and for Apple Silicon macOS, while Intel Macs are told to use the Linux image in Docker or build from source. Homebrew and a Docker path are documented as alternatives, and the first thing to do in a Docker run is pull the image, since the published image ships without a default configuration command, so you mount the file and name the command yourself:

docker run --rm -p 8080:8080 \
  -v "$PWD/sb.yml:/etc/sbproxy/sb.yml:ro" \
  soapbucket/sbproxy:latest serve -f /etc/sbproxy/sb.yml

The workspace holds around forty crates, and the Cargo configuration explains why a plain cargo build stays fast: the Kubernetes operator and the Gateway API controller pull in kube dependencies that add 30 to 60 seconds to a cold build, so they are excluded from default members while continuous integration still builds them. Releases v1.10.0, v1.11.0 and v1.14.0 landed in August and September 2026, and the last push was September 11, 2026.

Editorial conclusion

sbproxy fits a platform team that has to apply one set of controls to several kinds of traffic at once, since the same pipeline handles an HTTP request, a model call and a tool call and the audit record looks the same for all three. It is not a lightweight reverse proxy: the workspace is dozens of crates and the feature list includes a Kubernetes operator, a semantic cache and attested metering. Before you deploy it, read the OWASP coverage document rather than the feature list, check whether the one uncovered purpose matters to you, and pin extension bundles by commit and digest rather than by branch.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes