Platform / Data plane + Control plane
Applications use the stable CyberPass API. Providers, upstream models, routes and rules change centrally.
Every request is linked to an organization, service account, active policy, requested alias and actual route.
The data plane processes AI traffic. The control plane manages organizations, access, providers, models and policies.
Authentication, limits, inspection, retries, circuit breakers, egress control and calls to the approved upstream.
Tenant-aware configuration and audit. The console does not sit in every request path as an external vendor cloud.
The built-in adapter works with an OpenAI-compatible upstream. A new protocol is added once as a reusable adapter type, not as a customer-specific fork.
An application team uses, for example, public-general. An administrator can replace the provider and upstream model without updating client code.
Runtime mapping
Rules are not hard-coded into customer code. A new version is simulated first, then activated and recorded in the audit trail.
Request/response mode, severity, replacement marker, custom dictionaries and constrained regex.
Observe or block, a numeric threshold and explainable identifiers for matched signals.
A sensitive request can be rerouted only to an approved private alias.
No gateway eliminates every risk. The architecture makes decisions manageable, visible and measurable.
| Scope | Current state | Boundary |
|---|---|---|
| Streaming | Protected | The response is buffered until response inspection is complete; token-by-token latency is not promised. |
| Provider protocols | OpenAI API | Other upstream protocols require a reusable adapter. |
| Availability | Pilot | Services can scale, but Compose PostgreSQL and Redis remain single-node. |
One OpenAI-compatible endpoint and an agreed policy are enough for a pilot.
Request a pilot →