Vengtoo authorization through AWS Bedrock AgentCore Gateway

Use Vengtoo as the authorization brain for MCP tool calls flowing through AWS Bedrock AgentCore Gateway. AgentCore lets you attach a REQUEST interceptor (a Lambda) that runs before a tool executes: that Lambda forwards each tool call to Vengtoo and enforces the verdict.

Vengtoo response	Meaning	Interceptor behavior
2xx	ALLOW	proceed: the tool runs
403 (any non-2xx)	DENY	return a deny response: the tool never runs

Documented: not yet live-run

Unlike the Kong and Envoy examples (which were run end-to-end), this one has not been executed against a real AgentCore Gateway: AgentCore Policy/interceptors are a preview feature and the exact event/response envelope shifts. We'll live-verify it in an AWS account before publishing. What is proven: the Vengtoo call itself (/mcp/v1/ext-authz, 2xx=ALLOW/non-2xx=DENY, argument-level) is the identical contract already live-verified on Kong and Envoy.

Prerequisites

1. An AgentCore Gateway fronting your MCP tools.
2. The interceptor Lambda deployed and attached as the gateway's REQUEST interceptor.
3. Lambda env: store the key in Lambda env or Secrets Manager, never in code:

   VENGTOO_API_KEY = vgt_live_...
   VENGTOO_PDP_URL = https://pdp.vengtoo.com/mcp/v1/ext-authz   # (default)

4. Tenant policies for the caller subject (e.g. database__query ALLOW, destructive database__execute DENY).

How it works

The Lambda handler:

1. Extracts the tool name + arguments and the caller subject from the interceptor event (defensive lookups, the envelope varies by AgentCore version).
2. POSTs an MCP tools/call to Vengtoo's ext-authz endpoint with Authorization: Bearer $VENGTOO_API_KEY and X-Vengtoo-Subject.
3. 2xx → proceed; non-2xx or any transport error → deny (fails closed). Requests with no tool name pass through untouched.

Because the full arguments object is forwarded, argument-level policies work: deny a destructive SQL statement while allowing a benign one on the same tool.

Notes: to confirm in your account

• The event field paths and the deny/allow response envelope an AgentCore REQUEST interceptor expects are the parts to verify: they're read defensively and flagged in the code. AWS's Lambda-interceptor contract is the moving piece; the Vengtoo half is stable.
• Subject is forwarded via X-Vengtoo-Subject. If AgentCore passes a JWT you'd rather Vengtoo derive the subject from, send the token instead and drop the header.

Security: Vengtoo does not independently verify the subject

The Lambda MUST set X-Vengtoo-Subject (or forward the JWT's verified claims) from AgentCore's OWN authenticated caller identity, never pass through an unverified client-supplied header or claim. Doing so allows subject impersonation within your tenant.

• AgentCore also ships Cedar / AgentCore Policy. This interceptor is for teams that want Vengtoo as the external PDP (argument-level ABAC, delegation, HITL, one audit trail across gateways) rather than in-gateway Cedar.