13-generic-provider

A second AI vendor, added without code

Generic provider: allowed request served by a non-OpenAI vendor

Valid JWT for a configured tenant that allows gemini-flash-lite. Shield routes that model to a GENERIC provider (Gemini preset: Google's OpenAI-compatible endpoint, Bearer key from a secret reference) through the egress proxy, so the answer comes from Gemini 3.5 Flash-Lite (upstream model gemini-3.5-flash-lite). The policy names the route's provider in x-policy-provider, which is signed into the decision evidence.

generic-providerallowprovider

FIXTURE

tenant_id"northwind-finance"

home_region"tst"

scopes

ai.chat.write

Defaults: iss = http://localhost/tst-issuer, aud = edge, exp = now+1h, kid = tester-rs256

EXPECTED OUTCOME

HTTP STATUS200

X-POLICY-DECISIONallow

X-POLICY-REASON<empty>

POLICY ENGINE EXPECTATION

POLICY ENGINE ALLOWtrue

DENY_REASON<null>

DENY_CATEGORY<null>

What this demonstrates

Companies add AI vendors as they go. Each new vendor still passes the same checks: only approved hosts, a key from the company's secret store, and a signed record of every request. Demo traffic only: on Gemini's free tier Google may use prompts to improve its products, so customer data goes to paid terms.

Vendor risk managementEU AI Act Art. 12 (record-keeping)

RUNNER

Execute scenario

Mints a JWT, sends the request through the live gateway, and compares the response against the expected outcome.

Requires the PolicyGate stack reachable on host ports 10000 / 8181.

WHY THIS MATTERS

Proves a vendor added as configuration (no new Shield code) is reached end to end: route, egress allowlist, credential placement and evidence.