Vengtoo authorization through Envoy

Envoy can use Vengtoo as the authorization brain for MCP tool calls. Envoy is the highest-leverage integration in the family: it's the CNCF data plane under Istio, Kuadrant, and Solo/agentgateway, so the same pattern carries to anything built on Envoy.

Vengtoo response	Meaning	Envoy behavior
2xx	ALLOW	proxy to the upstream MCP server
403 (any non-2xx)	DENY	return 403, never reach the upstream

Verified

Live-verified against pdp.vengtoo.com: 200 (allow) / 403 (deny) / 200 (argument-level allow on the same tool) through a real Envoy.

How it works

An Envoy HTTP listener runs a Lua HTTP filter before the router. On each request the Lua buffers the JSON-RPC body and httpCalls the vengtoo_pdp cluster (POST /mcp/v1/ext-authz, over TLS, with Authorization: Bearer $VENGTOO_API_KEY and x-vengtoo-subject). On 2xx the request proceeds to the upstream; on non-2xx the Lua responds 403 and the upstream is never hit. Fails closed: a PDP/transport error yields status 500 → deny.

Notes: three things that will bite you

• Why a Lua filter and not native ext_authz? Envoy's ext_authz HTTP filter appends the downstream request path to its path_prefix, so it cannot cleanly hit Vengtoo's fixed /mcp/v1/ext-authz route (a mismatched path 404s, which ext_authz reads as DENY, blocking everything). The Lua httpCall gives exact control over path and body, the same approach Kong's pre-function uses. A native ext_authz + experimental MCP filter (envoy.filters.http.mcp, exporting tool params as dynamic metadata) is the emerging alternative for argument-level decisions, but that filter is not GA: track it, don't ship on it.
• content-length is required. Envoy's Lua httpCall does not derive it from the body; without an explicit content-length header the authorizer reads an empty body and pass-through-allows everything.
• The method is respond, not respondWith. A wrong name silently no-ops the deny.

Other notes:

• TLS. The PDP cluster validates against the image's system CA bundle with sni: pdp.vengtoo.com.
• Subject. Forwarded via x-vengtoo-subject on the API-key path; with JWT bearer auth the PDP derives the subject from the token.

Security: Vengtoo does not independently verify the subject

The PEP/gateway MUST set x-vengtoo-subject (or the JWT's verified claims) from its OWN authenticated session, never pass through an unverified client-supplied header or claim. Doing so allows subject impersonation within your tenant.

• Productizing. Move the inline Lua into a packaged filter so the PDP URL / subject / key are configurable per-route instead of via env substitution.