AI Pilot Quick Start

Audience: Platform engineers, AI governance admins
Time: < 20 min

Get AI Pilot enforcing controls on your first LLM or GenAI path: register a bouncer, bind AI assets, activate a control, and confirm decisions in Traffic / Activity.

What

AI Pilot sits on the bouncer traffic path. Every call to an LLM, MCP server, or GenAI tool can be authorized, inspected (PII + safety), and limited for cost — without changing application code.

Why

Enterprises need one place to prove who can use which models, that sensitive data does not leave the boundary, and that spend stays within budget. AI Pilot delivers that at the edge before traffic reaches providers.

How — choose a path

Path	Enterprise label	Best when
A	Gateway Mode	One shared bouncer fronts many apps/LLM routes (DNS or load balancer points at the bouncer).
B	App-Embedded	The bouncer runs next to a single app; that app sends AI traffic to localhost (or the shared pod network).

Both paths use the same Control Plane and the same AI Inspection Engine for PII and prompt safety. See Deployment modes (AI Pilot) for a full comparison.

Prerequisites

Control Plane healthy and reachable
Sandbox (or production) API key for the bouncer
At least one LLM or GenAI endpoint you can reach from the bouncer network

Path A — Gateway Mode (~15 min)

Deploy the bouncer in Gateway Mode in front of your LLM or GenAI upstream (~5 min).
Register — open Settings → PEPs / Bouncers and confirm the bouncer appears with a fresh heartbeat (~2 min).
Bind AI assets — in Settings → Resources (or AI Pilot → Intercept Scope), attach LLM / MCP / agent resources to this bouncer (~3 min).
Activate a first control — open Controls, pick an AI-related template (or a simple allow-by-role control), deploy to sandbox (~5 min).
Point clients at the bouncer endpoint as the LLM base URL (not the provider directly).

Troubleshooting: If the bouncer never appears, check Control Plane URL and API key on the host, then curl the Control Plane health endpoint. Full guide: Troubleshooting.

Path B — App-Embedded (~15 min)

Deploy the bouncer beside the application (same host or pod) (~5 min).
Register and confirm heartbeat in Settings → PEPs / Bouncers (~2 min).
Bind the app’s AI resources to that bouncer (~3 min).
Activate a first control in sandbox (~5 min).
Route the app’s AI egress through the local bouncer listen port so nothing bypasses governance.

Troubleshooting: App still reaches the LLM directly? Confirm the app’s base URL points at the bouncer, not the provider. Bypass defeats AI Pilot.

Verify

Send a test chat/completions (or GenAI) request through the bouncer.
Open AI Pilot → Activity (or Traffic) for that bouncer — you should see the request with decision, model, and any inspection actions.
Open Audit (platform or AI Pilot Audit tab) and confirm a matching decision for your caller.

Expected HTTP	Meaning
200	Allowed; forwarded (possibly with redaction).
403	Control denied access.
400	Safety / prompt guard blocked.
429	Token or rate limit exceeded.

Troubleshoot

Symptom	Where to look	Resolution
No Activity rows	Bouncer heartbeat; client base URL	Fix registration; ensure traffic hits the bouncer
Control not enforced	Controls → sandbox status; Policy Bridge sync	Activate control; wait for sync; retest
Limits inconsistent	Cost settings; Redis	Enable shared Redis for multi-replica token limits

Technical reference (env vars)

Enterprise labels map to deployment settings as follows (names only — values depend on your install):

Enterprise label	Typical setting	Upstream target
Gateway Mode	`BOUNCER_TYPE=reverse-proxy`	`TARGET_HOST` = shared upstream (API or LLM gateway)
App-Embedded	`BOUNCER_TYPE=sidecar`	`TARGET_HOST` = local app listen address (often loopback)

Also set Control Plane URL, API key, bouncer ID, environment, and provider credentials (OPENAI_API_KEY, Azure endpoint, etc.) as documented in Network Bouncer configuration.