Vengtoo authorization through agentgateway

Run agentgateway with Vengtoo as the authorization brain for MCP tool calls. agentgateway forwards each tool-call request to a Vengtoo ext_authz endpoint and enforces the verdict.

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

Why agentgateway is worth a dedicated integration:

• MCP-native: it speaks the MCP transport directly (backends.mcp) and includeRequestBody hands Vengtoo the exact tools/call envelope (method + tool name + arguments) needed for argument-level authorization.
• A2A / multi-agent native: agent-to-agent hops go through the gateway, which is exactly where Vengtoo's delegation/attenuation and human-in-the-loop belong.

Two enforcement tiers

Both use the same extAuthz block; only the host changes.

1. Data-local (recommended): agentgateway → a local Vengtoo agent on the host. The agent evaluates a synced policy bundle in-memory and returns the verdict. Tool arguments (SQL, prompts, PII) are authorized locally and never leave the host.
2. Hosted: agentgateway → pdp.vengtoo.com/mcp/v1/ext-authz. A tiny adapter shim can assert the agent subject and inject the Authorization: Bearer header if your agentgateway build doesn't support static ext_authz request headers.

How it works

One bind / listener / route with an extAuthz policy and an mcp backend. In the route's policy chain agentgateway POSTs the request body before proxying to the backend; 2xx falls through, non-2xx short-circuits to 403.

Delegation (multi-agent, A2A)

Documented pattern

Not a result this integration live-ran. The enforcement lives in the brain (policy-service), so it applies to the MCP ext-authz path automatically: nothing agentgateway-specific is required.

agentgateway is A2A-native: agent A can reach agent B through the gateway. That hop is exactly where privilege escalation by proxy must be stopped. Vengtoo enforces attenuation: the effective permission is the intersection of the whole delegation chain (A → B → C…). A tool call is allowed only if the agent's own policy allows it and every delegator up the chain also allows it, within each delegation's scope. Authority can only ever narrow. See Delegation.

Human-in-the-loop (HITL)

Documented pattern

Not a result this integration live-ran.

Flag a policy requires_human_approval and, instead of ALLOW, Vengtoo returns authorization_pending: it records an approval request and returns a not-yet-allowed response. On the 2xx/403 contract a pending decision is not a 2xx, so agentgateway holds the tool call until a human decides via POST /approvals/:id/approve|deny. The agent re-drives the call and gets ALLOW/DENY: a CIBA-shaped poll loop. See Human-in-the-loop.

Notes

• Proven vs. documented. The ext_authz wiring (forwarding the tools/call body via includeRequestBody) was proven by the spike this integration is built from; the allow / deny / argument-level behavior is the same Vengtoo decision path live-verified through Kong. Delegation and HITL are documented brain behaviors, not live-run here.
• Static ext_authz headers are version-dependent: the data-local tier sidesteps this entirely (the local agent needs no bearer).
• Image tag: verify the agentgateway image tag against its releases, since the config schema can evolve between versions.

Security: Vengtoo does not independently verify the subject

The PEP/gateway MUST set the subject (via the asserted header/config 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. A hardcoded demo subject (e.g. the adapter shim's agent:cursor) is a demo convenience, not a pattern to ship.