Skip to main content
Xenovia Runtime is a high-performance Go service that speaks the OpenAI wire format. It exposes two inference routes per agent and passes every inference request through a fixed pipeline before and after the upstream model call. It also serves the Python SDK’s decision endpoint POST /v1/execute, which checks one stage and returns a decision without calling a model.

​
Request flow

Before any plugin runs, the router prepares the request: it validates the agent ID, checks the path, method, and content modality, sets the internal X-Xenovia-Agent-Path, authenticates the key against the agent in the URL, and only then resolves the agent’s provider — rewriting the request’s model to the agent’s configured provider and model. Then the plugin pipeline runs.
Path, method, and body validation happen before authentication, so an unauthenticated caller can receive a 400, 404, or 405. Every key that cannot act as the agent in the URL — unknown, revoked, another agent’s, or a key for a draft or deleted agent — gets the same 401 invalid api key for this agent. A provider misconfiguration (502) is reported only to an authenticated caller.
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 agent_id and org_id.
  • The key’s agent must match the agent ID in the URL, unless the request carries a workflow header for same-organization cross-agent delegation.
  • Organization keys (ak_...) are rejected here — they authenticate the management API, not the runtime.
  • 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, 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. Billing

There is no per-agent rate limit. The runtime checks the organization’s request allowance and returns 402 when it is exhausted or billing access is restricted.

​
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 agent and revalidated about every five minutes.

​
6. Guardrails

The intent check and its triggers are gone; the agent’s guardrails run instead, evaluated by Xenovia’s guardrail service: model_request guardrails after the request-stage policies, then model_response guardrails and a tool_call guardrail per proposed tool call after the model replies. tool_result, memory_write, and context_summary guardrails run only through the SDK.
  • A guardrail escalate lets the request proceed; a block returns 403.
  • The block or escalation reason is recorded server-side and never returned to the caller.
  • There is no fail mode setting: an enforced guardrail that cannot be evaluated fails closed with 503, and a Monitor guardrail that fails records the error and never blocks.

​
Supported providers

Xenovia speaks OpenAI format to your app and translates each request for the provider upstream, so your app always uses an OpenAI-compatible client. More than forty providers are supported: model developers (OpenAI, Anthropic, Google, Mistral, xAI and others), cloud platforms (Azure OpenAI, Microsoft Foundry, Amazon Bedrock, Google Vertex AI, Databricks), inference providers, routers, self-hosted servers and any OpenAI- or Anthropic-compatible endpoint. See Supported providers for the full list and the credentials each takes. The provider your policy sees in input.provider is the provider’s type as configured (openai, microsoft-foundry, together, …), whatever API the runtime uses to reach it. A provider configured with a custom base URL keeps its type.

​
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 agent’s 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. Loopback and private vLLM addresses are rejected unless the runtime sets XENOVIA_ALLOW_PRIVATE_PROVIDER_ENDPOINTS (see Hybrid deployments).
  • Config integrity. Config snapshots and identity blobs are HMAC-signed. A revoked agent 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.

​
Hybrid deployments

A hybrid agent is served by the runtime in your own cluster. Its provider uses a credential reference that your cluster resolves at request time, and its endpoint is your deployment’s ingress URL followed by /{agent_id}/v1. These runtime settings govern guardrails and model routing in a hybrid deployment:
Without GUARDRAIL_URL, every guardrail errors: enforced guardrails fail closed with 503, and Monitor guardrails record an error. Policies do not depend on it.