Skip to main content
The Xenovia Python SDK (xenovia-sdk) gates agent tool calls, database writes, API requests, and any other action against Xenovia policy — without proxying an LLM call. Use it alongside proxy mode for end-to-end governance. Install:
Requirements: Python ≥ 3.9. Zero runtime dependencies (stdlib only).

How it works

The SDK sends an action intent — a capability string plus a payload — to the Xenovia backend via POST /v1/execute. The backend evaluates your Rego policy and returns a typed decision. Your function executes locally if allowed. No LLM is involved.

Initialise the client

Constructor parameters

unreachable_mode values:

execute() — one-off policy check

Capability inference: if capability is omitted, the SDK infers it from the caller’s module and function name (module.function_name) using frame inspection.

@guard() — decorator

Wraps a function with policy-aware gating. In enforce mode (default), the function body does not execute if the policy denies the action.
The decorator returns a XenoviaResponse. Access .result for the function’s return value when allowed:
Guard modes: Payload extraction: the decorator extracts the payload from the function call in this order:
  1. Explicit payload keyword argument
  2. Single dict positional argument
  3. Scalar argument → {"value": arg}
  4. Multiple args → all args as a dict
  5. No args → {}

XenoviaResponse — response object

Session handling

With auto_session=True, the SDK generates a session UUID on the first call and reuses it for subsequent calls on the same client instance:
Pass an explicit session_id to override auto-session:

Error handling

Wire format

The SDK sends POST /v1/execute with:

Security

  • HTTPS is enforced unless allow_insecure_http=True (restricted to localhost/loopback only).
  • The API key is sent only in the Authorization: Bearer xe_... header — never in payloads or logs.
  • No payload logging in debug mode; only the decision outcome and trace ID are printed.

Full example: governed tool call