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:
How it works
The SDK sends an action intent — a capability string plus a payload — to the Xenovia backend viaPOST /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 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.
XenoviaResponse. Access .result for the function’s return value when allowed:
Payload extraction: the decorator extracts the payload from the function call in this order:
- Explicit
payloadkeyword argument - Single
dictpositional argument - Scalar argument →
{"value": arg} - Multiple args → all args as a dict
- No args →
{}
XenoviaResponse — response object
Session handling
Withauto_session=True, the SDK generates a session UUID on the first call and reuses it for subsequent calls on the same client instance:
session_id to override auto-session:
Error handling
Wire format
The SDK sendsPOST /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.