Skip to content

AI governance

This page describes what XTM One shares with AI providers, where that data is processed, and how to control it. Read it alongside Data flow, which covers the request lifecycle and where data is stored.

What is shared with an AI provider

When the platform calls an AI provider, the request contains only what the model needs to answer:

  • the agent's persona and system instructions
  • the current conversation or assignment prompt, including recent message history
  • context the agent pulls in to answer — for example, snippets retrieved from a knowledge base, tool results, or an incoming trigger payload
  • the definitions of the tools the agent may call (names and parameters, not their results until a tool runs)

What stays private and is never included in the request to the model:

  • stored integration and channel credentials (encrypted at rest — see Configuration)
  • user passwords and session tokens
  • knowledge bases in full — when an agent answers, only the snippets it retrieves are sent (the full text is sent once to the embedding model when you first add the content, as described below)

XTM One does not train on your data

XTM One never uses your prompts, documents, conversations, memories, or any other data to train, fine-tune, or improve an AI model. Your data is sent to the AI provider you configure only to answer your own requests, in real time. The platform itself trains nothing.

Your AI provider sees your prompts

Whatever an agent puts into a prompt — including retrieved documents and tool results — is sent to the AI provider you configured. The platform does not anonymize, tokenize, or redact prompt content before sending it, and prompts are stored unredacted in your own deployment (see Data flow). Whether the provider retains or trains on the prompts it receives is governed by its terms, not by XTM One — review them, and scope agents' knowledge and tools accordingly. For maximum control, run a local model so no prompt data leaves your network.

Adding documents to a knowledge base

To make a knowledge base searchable, XTM One first has to turn its documents into numbers a computer can compare — these numbers are called embeddings. Creating them means sending the document text to an embedding model, which is an AI provider just like the one that answers questions.

Two things are worth knowing:

  • This happens when you add the content, not on every question. The same applies to an agent's saved memories.
  • The embedding model can be a separate provider from the one that answers chats — and it can be a local one (for example Ollama), so the document text never leaves your network. You set it under Settings → AI Models.

Where the AI provider runs

You choose the AI provider under Settings → AI Models, or pre-provision it (see the supported providers in Configuration). The provider determines where prompt data is processed:

  • Hosted providers (such as OpenAI, Anthropic, Gemini, and Mistral) process prompts on their own infrastructure, subject to their terms.
  • Self-hosted or local providers (Ollama, or any OpenAI-compatible endpoint on your network) keep prompt data inside your perimeter. This is the recommended option for air-gapped deployments.

Scope what agents can access

Because an agent only shares what it is configured to use, you control exposure by scoping the agent:

  • limit which knowledge bases an agent can read
  • limit which integrations and tools an agent can call
  • use assignment-level scoping to further narrow tools and knowledge bases per automation

See the User Guide for how agents, knowledge bases, and tools are configured.

Guardrails and safety

XTM One adds several safety layers around every agent run. They lower the risk of misuse, but they are not a substitute for limiting what each agent can access and choosing your AI provider carefully.

  • Per-agent rules — every agent has a separate "guardrails" box where you write hard rules it must always follow (for example, "never send external email" or "only answer questions about our products"). These rules are kept apart from the agent's persona, so an edit to its personality can't accidentally erase them.
  • Injection detection (alert only) — messages coming into an agent are checked for known tricks that try to make the AI ignore its rules ("prompt injection" and "jailbreak" attempts). When one is spotted, XTM One records it as a security event for administrators to review — but it does not block the message. Treat this as an alert to check, not a wall that stops every attack.
  • Treating outside content as data, not orders — anything an agent pulls in from the outside world (web pages it fetches, incoming webhook or integration messages) is wrapped so the AI treats it as information to read, never as instructions to obey. This helps stop a malicious web page or email from hijacking the agent.
  • Built-in security rules — a fixed set of security instructions is added to every agent so it resists attempts to reveal its hidden instructions, override its rules, or pretend to be someone else.
  • Link checking — when an agent's answer includes links to other XTM Suite products, XTM One checks and corrects them automatically, so the agent never hands out made-up links.

Data retention

All platform data lives in your own deployment (see Data flow). XTM One applies these defaults:

Data Where it is stored Default retention How to control it
Conversations and messages PostgreSQL Kept until deleted Delete the conversation, or the agent it belongs to
Assignment runs and results PostgreSQL Kept until deleted Delete the run, or the assignment
Agent memory — recent interactions Redis 24 hours (auto-expires) Automatic
Agent memory — rolling summary Redis 30 days (auto-expires) Automatic
Agent memory — long-term facts PostgreSQL 90 days, max 200 per agent Admins can clear an agent's memory at any time
LLM traces PostgreSQL (or ClickHouse) Purged after the retention period — 90 days by default Adjustable from 1 to 365 days under Settings → Observability; individual traces can be deleted
Daily observability aggregates PostgreSQL Kept indefinitely — they outlive the trace purge on purpose Not covered by the trace retention setting; see What survives the trace purge
Audit logs PostgreSQL Kept indefinitely (immutable) Admin-only visibility

What survives the trace purge

Deleting an expired trace does not delete the KPI it contributed to. Once a day is complete, XTM One rolls its traces up into a small daily aggregate and keeps that aggregate indefinitely, so the Analytics dashboard can still answer "what did last quarter cost?" long after the individual traces are gone. This is why a 30-day or 90-day chart still has data on a platform with 7-day trace retention.

What you keep, and for how long:

Individual traces Daily aggregates
Retained for The retention period (1–365 days, default 90) Indefinitely
Granularity Every request, with prompts, tool calls and errors One row per day, agent, model, source and user
Answers "What exactly happened in this conversation?" "How much did this agent, model or person cost, and how fast was it?"
Where in the UI Trace explorer, individual trace detail, top errors Cost, volume and latency charts on Analytics

Consequences worth knowing before you choose a retention period:

  • Prompt and response content is not aggregated. Only counts, token totals, cost, latency distributions and feedback averages survive. Nothing a user typed, and no tool result, outlives the retention period.
  • Aggregates are per user. A day's row is keyed by agent, model, source and the user who made the request, so per-person usage and cost stay answerable after the traces are gone. If your retention policy requires per-user usage records to expire as well, treat these aggregates as in scope — the trace retention setting does not clear them.
  • Error details and per-request diagnostics do not survive. The "Top errors" table and trace detail are served from raw traces only, so they are always limited to the retention window.
  • Latency beyond the window is a distribution, not the raw timings. Each day stores a bucketed histogram of its durations, which is what lets percentiles be merged correctly across a long window. Expect percentile values to be accurate to within a bucket rather than exact.
  • A day is never purged before it is aggregated. The maintenance job aggregates first and refuses to delete a day that has no aggregate yet, so lowering the retention period (or a restart longer than it) cannot silently drop a day's KPIs. If a window you select reaches back further than any surviving data, Analytics says so instead of showing zeroes.
  • ClickHouse retention is out-of-band. With tracing_store_provider=clickhouse, the retention setting governs the PostgreSQL copy; expiry of the ClickHouse tables is up to your own TTL or housekeeping. Long-window dashboards read the PostgreSQL aggregates either way.

To remove the aggregates as well, delete the llm_daily_stats rows (or the deployment's PostgreSQL volume, as below).

Two categories are not retained by XTM One and are governed entirely by your own infrastructure:

  • Application logs are written to standard output. Your container runtime or log aggregator decides how long they are kept and how they are rotated — see Monitoring.
  • Metrics are exposed on the /metrics endpoint and scraped by your Prometheus. The platform holds only current values; historical retention lives in your monitoring stack.

To remove all data, delete the deployment's PostgreSQL, Redis, and object-storage volumes. For selective deletion, delete the specific agents, conversations, or knowledge bases from the application.

Next step

Review Monitoring to see how AI requests are traced and observed, and Authentication to control who can send them.