Skip to main content
Xenovia Runtime is a high-performance Go proxy that speaks the OpenAI wire format. It exposes two routes per proxy and passes every request through a fixed pipeline before and after the upstream model call.

​
Request flow

Before any plugin runs, the router prepares the request: it validates the proxy ID, checks the path, method, and content modality, sets the internal X-Xenovia-Agent-Path, and resolves the proxy’s provider — rewriting the request’s model to the proxy’s configured provider and model. Then the plugin pipeline runs.
Provider resolution and JSON parsing happen at the router, before authentication. An unauthenticated caller can therefore receive a 400 (bad body) or 502 (provider misconfiguration) from a proxy route.
A session middleware wraps the whole router and stamps X-Xenovia-Session-Id and X-Xenovia-Trace-Id into the response headers before the first body byte, so streaming responses still carry them.

​
Plugin details

​
1. Auth

  • Accepts x-xenovia-key: xe_... or Authorization: Bearer xe_....
  • Resolves the key against Redis (apikey:{sha256(key)}, 5-minute TTL). On a miss it calls the control plane; a resolved identity is an HMAC-signed blob holding proxy_id and org_id.
  • The key’s proxy must match the proxy ID in the URL, unless the request carries a workflow header for same-organization cross-proxy delegation.
  • Organization keys (ak_...) are rejected here — they authenticate the management API, not the proxy.
  • Keys are never logged; only an 8-character SHA-256 prefix appears in logs.

​
2. Session

Five strategies, first match wins: Turn numbers increment per session (30-minute sliding TTL). Sessions are isolated per API key for strategies 2–4, and cross-organization reuse of an explicit session ID is rejected.

​
3. Trace

  • Opens a turn record and emits child runs: the model call, plus policy, intent, escalation, and runtime-executed tool runs.
  • Custom X-Xenovia-Property-* headers are attached to the turn (see Traces and Remediation).
  • Persistence is asynchronous. Under sustained overload a record can be dropped rather than block the request.

​
4. Rate limit

Enforces the proxy’s rate_limit_rpm when one is configured; by default there is no limit. Over the limit returns 429 (no Retry-After). This stage runs after tracing so rate-limited requests are still recorded.

​
5. Policy

Evaluates the request-stage Rego against the full request context, then the response-stage Rego after the model replies. See Policies and Enforcement for the decision contract and the input schema. Policies are cached per proxy and revalidated about every five minutes.

​
6. Intent

An optional semantic guardrail. When the proxy has an intent defined and the trigger fires, the request is scored against it:
  • Trigger axes: turn_scope (all, first, first_n), on_tools (ignore, require, always), min_content_chars, and sample_rate.
  • Actions: allow, block (403), or escalate (403 plus an escalation signal).
  • The block or escalation reason is recorded server-side and never returned to the caller.
  • Fail mode is open by default (scoring failures allow the request); it can be set to fail closed, which returns 503 on a scoring error.
The dashboard and alerts label this feature Guardrail, while proxy configuration calls it Intent. They are the same thing.

​
Supported providers

Xenovia speaks OpenAI format and translates to each provider upstream, so your app always uses an OpenAI-compatible client. An OpenAI-typed provider configured with a base URL is routed as vLLM; one configured for Azure (an Azure endpoint or API version) is routed as Azure. The provider your policy sees in input.provider is this resolved value.

​
Supported endpoints

Embeddings, legacy completions, model listing, and audio, image, video, batch, and container endpoints are not routed and return 404. Only these two inference routes and the health endpoints are served. Text, image, and file inputs are accepted on both routes; audio output and other modalities are rejected with 400.

​
Security

  • Credential isolation. Provider credentials live in the proxy configuration and are resolved server-side; your app never holds them. Secrets are fetched over an internal channel and kept in memory, never written to Redis or into telemetry.
  • SSRF protection. vLLM and Azure base URLs are validated; link-local and cloud-metadata addresses are rejected.
  • Config integrity. Config snapshots and identity blobs are HMAC-signed. A revoked proxy key stops working within about five minutes in the cloud.
  • Deployment. In the standard cloud deployment Xenovia operates the runtime. A hybrid data-plane option runs the runtime inside your own cluster; ask your Xenovia contact for the deployment guide.