🤖 Control Core AI Pilot: AI Governance and Use

Control Core AI Pilot (AI Pilot) is Control Core’s AI governance layer. It lets you govern how AI is used across your organization: who can use which models, what data reaches LLMs, prompt safety, and cost—all enforced at the bouncer before traffic reaches your LLMs, GenAI tools, or data.

This guide explains how AI Pilot supports AI governance, where to place the bouncer, how it works, and how to use and configure it.

🤖 How AI Pilot supports AI governance

AI Pilot helps you govern AI usage in four ways:

Governance is enforced at the bouncer: every request to your LLMs or GenAI tools passes through the bouncer, where policy, PII redaction, prompt guard, and token limits are applied. You configure these once in the Control Plane (Settings → AI Pilot); bouncers receive the config and apply it automatically.

🤖 Where to place the bouncer: governing AI across your stack

Place the Control Core bouncer (with AI Pilot) in front of every AI-facing asset you want to govern. All traffic from users, apps, or services to those assets should go through the bouncer so access, data, safety, and cost are enforced in one place.

Placement diagram

Rule: Put the bouncer between callers (users, apps, AI chat UIs) and the assets you want to govern. The bouncer does not sit behind the LLM; it sits in front of it.

What to put behind the bouncer

Summary

• In front of: Users, applications, AI chat UIs (they send requests to the bouncer).
• Behind: LLMs, GenAI tools, AI chat backends, and data assets (the bouncer forwards allowed, sanitized requests to them).

This way you govern all AI traffic and data access in one place, with one policy and one set of safety and cost controls.

🏗️ How governance is applied (request flow)

When a request goes to an LLM or GenAI asset through the bouncer, AI Pilot applies governance in this order:

1. Authorization (OPA) – Allow or deny by user, path, model. Deny → 403.
2. PII redaction – For LLM paths, prompt (request body) is redacted; for APIs, response masking as configured.
3. Prompt guard – Forbidden phrases in prompts → block (400) or sanitize and log.
4. Token / rate limits – If configured (and Redis is used for token limits), over limit → 429.
5. Forward – Allowed, sanitized request goes to the LLM provider, GenAI tool, or data asset.

Request and response (both directions)

The AI Gateway governs both directions of traffic: client → LLM (request) and LLM → client (response). The bouncer sits in the middle, so every request and every response passes through it.

• Request path (client → bouncer → LLM): Authorization, PII redaction in the prompt, prompt guard, token limits; then the sanitized request is forwarded to the LLM.
• Response path (LLM → bouncer → client): The LLM response flows back through the bouncer. You can apply response-body masking (e.g. PII in model output) so that data leaving the LLM is governed before it reaches the client. Policy can define which fields to mask or redact in the response.

So governance applies in both directions: who can send what to the model, and what the client is allowed to see in the response.

Detailed sequence (request path):

🤖 AI governance capabilities in detail

Real-time PII redaction

• Prompts (request path): The bouncer redacts PII in LLM request bodies (e.g. messages[].content) using policy or built-in patterns (SSN, credit card, email, etc.) and sends only sanitized content to the provider. Raw PII does not leave your boundary in the prompt.
• Responses (response path): For standard API traffic, response bodies are masked as today. LLM responses can optionally be masked as well—the bouncer applies policy-driven response masking so PII or sensitive content in the model output is redacted before it reaches the client. So governance applies in both directions: request to the LLM and response from the LLM.

Model-agnostic routing and access

• Paths like /v1/chat/completions, /v1/completions, /v1/embeddings are routed to the right LLM backend.
• Headers or body (e.g. model field) can select OpenAI vs Azure OpenAI. OPA policy enforces who is allowed to use which model (e.g. “Interns cannot use GPT-4”); denied calls get 403 before reaching the LLM.

Cost and token tracking

• Token limits (e.g. 1,000 tokens per user per day) are enforced when configured; Redis is required for global limits across replicas.
• Token usage and rate-limit rejections can be used for dashboards and audits.

Prompt guard (jailbreak protection)

• The bouncer scans LLM request bodies for forbidden phrases (e.g. “ignore all instructions”). Matching prompts can be blocked (400) or sanitized and logged. Phrases are configurable in the Control Plane (AI Pilot settings).

📌 Configuration and management (administrators)

AI Pilot settings are managed in the Control Plane so you don’t edit config on each bouncer. This is the standard way Control Core manages bouncers.

Where to find AI Pilot settings

Settings → AI Pilot (or AI Pilot (AI Gateway)), or the AI Pilot item in the sidebar → Configure AI Pilot.

Tabs and what they do

How config reaches bouncers

AI Pilot config is stored in the Control Plane (global and optional per-bouncer). Bouncers fetch it with the rest of their config (e.g. effective config API) and apply it on the next fetch or reload; no restart required.

FAQ: bouncer topology for LLM-connected resources

What you still set on the bouncer (deployment)

• Control Plane URL, API key, Bouncer ID, environment, target host/port.
• For LLM traffic: OPENAI_API_KEY, OPENAI_BASE_URL, or AZURE_OPENAI_ENDPOINT.
• REDIS_URL if you use token-based rate limiting across replicas.

📌 For users and app owners

What AI Pilot does for your traffic

When your app or an end user sends an LLM request through a bouncer with AI Pilot enabled:

1. Authorization – Policy decides if the caller may use the requested model/path; if not → 403.
2. PII protection – Prompts are redacted before being sent to the LLM.
3. Prompt guard – Forbidden phrases → request blocked (400) or sanitized and logged.
4. Token/cost – If limits are set (and Redis is used), over limit → 429.

You don’t change application code; the bouncer applies this transparently.

What to expect when calling the bouncer

💡 Use cases

1. Govern LLM access and safety (admin)

Goal: Only allowed users/models can call the LLM; prompts are protected and jailbreak attempts blocked.

Steps: Deploy the bouncer with AI Pilot in front of your LLM provider(s). Configure Settings → AI Pilot (LLM Connections on, AI Pilot Features → prompt guard and forbidden phrases). Define policy in the Control Plane for who can use which model. All LLM traffic goes through the bouncer; access, PII, and prompt guard are applied automatically.

2. Enforce token budgets per user (admin)

Goal: Cap usage at e.g. 1,000 tokens per user per day and 30,000 per month.

Steps: Set REDIS_URL on the bouncer. In Settings → AI Pilot → Cost, set daily and monthly token limits and save. Bouncers with Redis will enforce these limits; over limit → 429.

3. Protect prompts to GenAI tools and data (admin)

Goal: All calls to internal GenAI tools or data lakes go through the bouncer so access and PII are governed.

Steps: Place the bouncer in front of your GenAI APIs and data access endpoints. Configure AI Pilot (LLM routes and/or standard API routes as needed) and policy. Route all client and service traffic to these assets through the bouncer.

4. Same governance in sandbox and production (admin)

Goal: Same AI Pilot settings (token limits, prompt guard, PII) in sandbox and production.

Steps: Configure Settings → AI Pilot once. Ensure sandbox and production bouncers use the same Control Plane (same tenant); they receive the same global AI Pilot config unless you set per-bouncer overrides.

📌 Smart Control Core Agent (chat copilot)

Smart Control Core Agent is the chat-first way to run policy lifecycle operations in plain language for non-technical users.

What it can do

• Create draft policies from natural-language requirements.
• Assist Rego authoring directly inside Policy Builder Code Editor using PBAC + PIP context.
• Validate policy code and run conflict/readiness checks.
• Activate/deactivate/promote policies with explicit confirmations.
• Open the Control Simulator and Audit Logs with context-aware deep links.
• Suggest missing PIP/data-source setup when metadata needed for a policy is unavailable.

Policy Builder code copilot (PBAC + PIP)

When you open Policy Builder → Code Editor, Smart Control Core Agent auto-activates as a coding copilot and keeps the interaction in plain language.

• Takes natural-language instructions and translates them into Rego-ready policy logic.
• Maps requests to PBAC dimensions:
  • Principal: who (user, service, AI agent) is requesting.
  • Subject/Resource: what protected resource is being accessed.
  • Action: what operation is requested (read/write/approve/deploy/etc.).
  • Context (PIP): dynamic attributes (risk score, device trust, location, department, MFA, time).
• Returns guidance as What / Where / Risk / Next Step with snippet-level evidence.
• Preserves human control: no automatic save, activate, or promote.

Dependencies for code copilot quality

• Connected PIP sources with mapped attributes (Settings → Data Sources).
• At least one active bouncer and mapped protected resource.
• Smart CC model provider configured in Settings → Smart Control Core.
• Rego validation path available (/policies/validate-rego) for rapid feedback.

Practical prompt patterns

• “In this policy, deny delete for contractors unless input.context.risk_score < 40.”
• “Add principal scoping: allow only finance managers in user.department for approve action.”
• “Use device trust and MFA signals from PIP before allowing production deploy.”
• “Refactor this rule to keep Regal-friendly style and explain missing attributes I need to map.”

Recommended flow

1. Open Smart Control Core Agent from Controls, Testing, or Audit pages.
2. Ask for a policy goal in plain language (no Rego/PBAC syntax required).
3. Review the response cards: What / Where / Risk / Next Step.
4. Confirm mutating actions only after simulation/conflict guidance.
5. Use suggested deep links to Controls, Control Simulator, and Audit Logs.

Policy Builder code assist (PBAC + PIP)

When you switch to Policy Builder → Code Editor, Smart Control Core Agent auto-activates as an in-editor copilot and uses sanitized builder context:

• Current draft context (resource, bouncer, effect, rego excerpt)
• PBAC intent from your natural language (principal, subject/resource, action)
• Connected PIP intelligence (available and missing attributes)

Typical prompts:

• "Add principal constraints for contractors and service accounts."
• "Restrict action to read-only unless risk score is low."
• "Use department and device trust from PIP for approval paths."

Expected output pattern:

• What: Proposed code patch/snippet in plain language
• Where: Target resource + bouncer + editor scope
• Risk: No mutation until user saves/activates
• Next Step: Insert/replace snippet, validate, run simulator

See full how-to: Policy Builder Code Assist with PIP Intelligence

Current limitations

• Draft generation depends on the configured LLM provider being reachable and authorized.
• If provider credentials/model access are invalid, draft creation is blocked (no mutation occurs).
• Some actions require policy context (policy_id or selected policy in UI) before execution.
• Simulation gates can block activate/promote until testing is completed.
• Code assist quality depends on available PIP mappings; missing signals are suggested but not auto-created.

Troubleshooting Smart Control Core Agent

For API-level verification, see AI Pilot troubleshooting and Control Plane logs.

🛠️ Troubleshooting

📌 Related documentation

• Network Bouncer Configuration – Deploying the bouncer, LLM env vars, Redis.
• Architecture – Unified bouncer and AI governance.
• Bouncer Deployment – Deployment patterns and pairing.
• Control Map Guide – Topology canvas, environment scope, active policy visibility, and deep links.
• Global Baseline Reference – Full variable reference, allowed values, and baseline examples.
• Policy Builder Code Assist – End-to-end PBAC+PIP in-editor copilot workflow.