Skip to main content
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.

​
How tool calls appear in traces

​
Tool definitions and model tool calls (agent endpoint)

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.

​
MCP tools executed by the runtime

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.

​
Governing tools with policy

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 lists the declared tool names exactly as your app sent them; comparisons are case-sensitive. input.tools carries the full schemas as input.tools[_].name, .description, and .parameters_schema; the keys of every tool object are lowercase. Use tool_names for allow/deny lists.

​
Block a tool by name

​
Allow only known-safe tools

​
Escalate a destructive tool for human attention

  • Least privilege. Blocklist high-risk tools explicitly rather than trusting a broad allowlist.
  • Separate by environment. Use different agents, or different policies on one agent, 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, and tool-argument size caps. 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 agent endpoint. To gate actions your code takes on its own — tool calls and results, memory writes, database writes, outbound API calls — use the Xenovia Python SDK.