Most agent risk comes from tool use, not text generation. Xenovia sees the tools an agent declares and the calls a model makes, and lets you govern them with policy.
When your app sends a chat/completions or responses request, the tool definitions you pass are visible to policy as input.tools and input.tool_names, and are recorded on the trace. When the model decides to call a tool, the tool calls it returns are captured on the turn as output.tool_calls (name, arguments, and call ID).
In the common pattern, your own code executes the tool and sends the result back as a tool-role message on the next request. That result is visible to the next request’s policy as input.tool_results and is recorded on that turn. Client-executed tools are not separate child runs — they live in the turn’s messages and output.
When a tool is executed through the Model Context Protocol by the runtime itself, Xenovia records it as its own child run with the tool name, arguments, result, status, and latency, alongside the model runs.
Tool governance is ordinary policy. The request-stage Rego sees the declared tools before the model is called, so a matching rule returns 403 before any tokens are spent. Read Policies and Enforcement first for the decision contract.
input.tool_names is a convenient lowercased list of the declared tool names. input.tools carries the full schemas, and its keys are capitalised — input.tools[_].Name, .Description, .ParametersSchema. Use tool_names for allow/deny lists.
Recommended controls
- Least privilege. Blocklist high-risk tools explicitly rather than trusting a broad allowlist.
- Separate by environment. Use different proxies, or different policies on one proxy, for
dev, staging, and prod. Never share production credentials.
- Escalate irreversible actions. Use
escalate for deletions, financial writes, and cross-system state changes so they surface in Sessions and Alerts.
- Review from evidence. Traces show which tools are actually called. Remove rules for tools that no longer appear.
Starting from a template
Several shipped policy templates cover tool access directly — for example an approved-tool allowlist, tool-argument PII blocking, tool-argument size caps, and human review for high-risk tools. Instantiate one from the dashboard or the management API rather than writing Rego from scratch.
Governing actions outside the model call
Tool governance here covers tools the model requests through the proxy. To gate actions your code takes on its own — database writes, outbound API calls, file operations — the Xenovia Python SDK is the intended path. Its hosted decision endpoint is not live yet; see that page before adopting it. 