Vengtoo authorization through Kong

Kong Gateway can use Vengtoo as the authorization brain for MCP tool calls, no Vengtoo-specific gateway required. Kong forwards each tool-call request to Vengtoo's ext_authz endpoint and enforces the verdict.

The contract is deliberately trivial so any gateway can speak it:

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

Verified

This integration is live-verified end-to-end (200 / 403 / 200 against the hosted PDP).

Prerequisites

1. Docker running.
2. Your Vengtoo API key exported in the shell:

   export VENGTOO_API_KEY=vgt_live_...

3. The tenant has MCP tool policies for subject agent:cursor:
   • database__query → ALLOW
   • database__execute (destructive SQL) → DENY

How it works

• A stock kong:3.7 image in DB-less mode fronts a mock MCP upstream. In Kong's access phase a pre-function plugin POSTs the raw MCP JSON-RPC body to Vengtoo with Authorization: Bearer $VENGTOO_API_KEY and X-Vengtoo-Subject: agent:cursor. A 2xx falls through to the upstream; any non-2xx short-circuits to 403. It fails closed if the PDP is unreachable.
• The deny lands on the destructive SQL, not the tool name: that argument-level decision is Vengtoo's job, the point of putting a policy brain behind the gateway.

To productize, move the same logic into a packaged Kong plugin (handler.lua access phase

• schema.lua for ext_authz_url / api_key / subject) so it's configurable per-route.

Notes

• Subject is forwarded because the API-key path carries no JWT sub. With JWT bearer auth, Vengtoo derives the subject from the token and the header is unnecessary.

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.

• Two Kong TLS settings are required for the outbound call to the hosted PDP and are easy to miss:
  • KONG_LUA_SSL_TRUSTED_CERTIFICATE: the CA bundle the Lua cosocket verifies against.
  • KONG_LUA_SSL_VERIFY_DEPTH=5: Kong defaults this to 1, too shallow for the PDP's Let's Encrypt chain (two intermediates), which fails with "unable to get local issuer certificate". Verification stays on; the depth just walks the full chain.
• KONG_NGINX_MAIN_ENV=VENGTOO_API_KEY: nginx strips the worker environment, so the key must be exposed explicitly or os.getenv returns nil in the Lua VM.