Bairav AI Gateway
The Bairav AI Gateway sits between your application and your model provider. Point your OpenAI-compatible client at the gateway URL and Bairav enforces your policies on every call, records the decision in the audit ledger and accounts for tokens and cost.
Your provider key stays yours. Send your real provider key in Authorization. The gateway forwards it to the provider and never stores it.
The gateway credential is in the URL path. A gateway key looks like bst_<8 hex>.<secret> and is part of every path (/gw/{token}/...). Treat the full base URL as a secret: it appears in access logs and shell history. Create and revoke gateway keys in the Bairav console, or with the Portal API (POST /api/gateway/keys, admin only).
How a call is decided
- Pre-flight check of the request shape.
- Kill switch: agents that are suspended, blocked or rejected are refused.
- Guardrail patterns on the latest user message.
- Optional AI judge, which can only escalate and fails safe.
- The request is forwarded to your provider.
- Post-call checks on tool calls and the answer, then your control policies (block, require approval, flag, notify).
- The decision, tokens and latency are logged.
Blocked calls look like normal answers. A refusal is returned as an OpenAI-shaped completion with HTTP 200 (as a stream if you asked for one) and the response header X-Bairav-Blocked: 1. Check that header, not just the status code.
The gateway fails open on its own errors. If a governance lookup fails internally, the call degrades to a plain proxy rather than breaking your application.
Authentication
- HTTP: Bearer Auth
Your own model provider key. It is forwarded to the provider and never stored by Bairav. The Bairav gateway key itself is the {token} path segment.
Security Scheme Type: | http |
|---|---|
HTTP Authorization Scheme: | bearer |
Contact
Bairav developer support: BTG.Support@prokraya.com