Vengtoo authorization through the Docker MCP Gateway

Use Docker's MCP Gateway with Vengtoo as the authorization brain for MCP tool calls. Docker's gateway runs an interceptor before each tool call; the interceptor asks Vengtoo for a verdict and blocks on DENY.

Vengtoo response	Meaning	Gateway behavior
2xx	ALLOW	run the tool
non-2xx	DENY	block the tool, upstream never hit

Because Docker passes the full tools/call JSON (including params.arguments) to the interceptor, the decision is argument-level: the deny can be on a destructive SQL statement, not just a tool name.

Two interceptor modes

• before:http:: the gateway POSTs each tool call to an HTTP endpoint (a tiny Node service, interceptor.mjs).
• before:exec:: the gateway runs a command with the tool call on STDIN (verdict via exit code, interceptor-exec.sh).

Both forward the call to https://pdp.vengtoo.com/mcp/v1/ext-authz with Authorization: Bearer $VENGTOO_API_KEY and fail closed if the PDP is unreachable.

Wire it in

export VENGTOO_API_KEY=vgt_live_...

# HTTP interceptor
docker mcp gateway run \
  --interceptor "before:http:http://localhost:8080" \
  --servers <your-mcp-server>

# or the exec variant
docker mcp gateway run \
  --interceptor "before:exec:/path/to/interceptor-exec.sh" \
  --servers <your-mcp-server>

What's proven vs. documented

Documented (not live-run here)

The Docker-gateway → interceptor wiring (--interceptor before:http: / before:exec:) was not executed end-to-end. The exact response shape / exit-code semantics vary by mcp-gateway version: the source files call this out inline; verify against your version and adjust the interceptor's reply if your build expects a different format.

Proven (by parity): the decision path (POST /mcp/v1/ext-authz, 2xx=ALLOW / non-2xx=DENY, argument-level deny on destructive SQL) is the same Vengtoo contract live-verified through Kong. The included test drives the interceptor → Vengtoo half directly against the live PDP.

Notes

• Subject is forwarded as X-Vengtoo-Subject on the API-key path; with JWT bearer auth the PDP derives it from the token.

Security: Vengtoo does not independently verify the subject

The interceptor 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.

• Fail-closed: both interceptors deny if the PDP call errors or times out.
• To harden, run the interceptor as a container in the same compose project as your MCP servers rather than on the host, and pin its image.