Security & Compliance

How Xantly protects your data: encryption, retention tiers, access controls, breach notification, sub-processors, and certification status.

This page summarizes Xantly's security posture for developers. For the full, canonical detail, see the marketing site's Security overview and the Data Processing Agreement.

Encryption

API keys are additionally bound with DPoP (Demonstrating Proof of Possession) to reduce the impact of a leaked token.

Data retention

Xantly uses a tiered content-retention model. You choose how prompt and response content is handled; metadata, audit, and billing records retain on separate clocks. By default (Tier 1), content is stored for a window you control and then auto-purged, Xantly is not a strict pass-through by default.

Retention windows, on independent clocks:

After retention periods expire, data is permanently deleted or irreversibly anonymized.

Derived routing signals

To route each request, Xantly computes non-reversible derived signals: token counts, an inferred task class, latency, cost, success outcomes, and a numeric semantic embedding. These train a per-customer routing policy (our Bayesian adaptive routing loop, BaRP) and update aggregate model-performance stats. Content text is not stored to produce these signals, and the signals cannot reconstruct it. For Zero-Retention accounts, no content-derived embedding is persisted.

No content used to train language models

Xantly never uses your prompts or responses to train, fine-tune, or improve any large language model, its own or a provider's. The only models Xantly trains are internal routing / selection models, trained solely on the non-content signals above. Any optional cross-customer aggregation for improving routing uses only aggregated, anonymized, non-content outcomes, and excludes Zero-Retention and opted-out customers.

When you route a request to a third-party provider, the content needed to fulfill it is sent to that provider and is then subject to that provider's own data-usage terms.

Access controls

Account and organization access is protected by:

• Authentication methods: passwords, passkeys (WebAuthn), MFA (TOTP), email one-time passcodes, and Google / GitHub social login.
• Organization RBAC: role-based access control scopes what each member can do within an organization.
• MFA for administrative functions: multi-factor authentication is required for sensitive administrative actions.
• API key scoping: assign each key only the permissions it needs, and rotate or revoke keys from the dashboard.
• Audit logging: administrative and security-relevant actions are recorded.

Enterprise single sign-on (SAML / OIDC SSO) is not available today.

Breach notification

If Xantly becomes aware of a personal data breach affecting data processed on your behalf, it will notify affected customers without undue delay and in any case within 72 hours. The notification describes, to the extent known, the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken to address it.

Sub-processors

Xantly uses a defined set of sub-processors to operate the Service. The content of a request is shared with a model platform only when your request is routed to a model running there.

Model platforms. Measured over the 90 days to September 9, 2026, these three carried 96.1% of all inference attempts.

Direct model providers. The remaining 3.9% of attempts reached a model vendor's own API, because the model was not available on a platform above or the platform attempt failed. The full list, with locations, is Annex III of the DPA. Several are outside the EEA, including in the People's Republic of China. If that conflicts with your data-residency requirements, enable Compliant Mode or set a routing policy, which confines routing to a verified catalog on the attested platforms above.

Infrastructure and business operations.

Everything else in the stack, including the database, cache, vector store, graph store, analytics warehouse, and monitoring, runs on infrastructure Xantly operates itself inside its own AWS account and is not a separate sub-processor.

The authoritative sub-processor list, and the 10 business day change-notification commitment, are in Annex III of the DPA.

Tool-result injection guard

An agent feeds whatever a tool returned, an inbox, a web page, a file, straight back to the model as a role: tool message, and an instruction planted in that data is the indirect prompt-injection problem. Xantly scores every tool-result message before any provider sees it, with an open classifier built for exactly this, run inside the gateway; no content leaves Xantly for the check.

A tool result is split along its structure (list items, paragraphs) and each piece is scored on its own, because an instruction hidden in one email of a listing is only visible when that email is looked at alone. What happens to a flagged piece depends on the mode. In log mode nothing is changed and the outcome is reported. In spotlight mode the piece is wrapped in delimiters that name it as untrusted data, and the model still reads it. Both are the classifier alone and add milliseconds. In redact mode a flagged piece is first confirmed by a second check, a small language model that reads that one piece and is told never to follow it, because the classifier alone also fires on ordinary data such as password-reset emails and security codes. A confirmed piece is replaced in place with a short marker, a piece the check clears is left exactly as it was, and one the check could not rule on is spotlighted, never removed. The confirmation calls are billed to your organization like any other routed usage. The request itself is never failed and never blocked.

The gateway sets the mode for everyone. A request can tighten it for itself, never loosen it, by sending the x-xantly-injection-guard: spotlight or x-xantly-injection-guard: redact request header, and xantly/auto-safety always redacts.

Every response whose request carried tool results reports the outcome in x-xantly-injection-guard (mode=<mode>;scanned=<chunks>;flagged=<n>;confirmed=<n>;redacted=<n>;spotlighted=<n>; confirmed counts the second check and is zero outside redact mode), and the same tally is on the request row in your usage export. The guard is a layer, not a guarantee: an adaptive attacker can write around any classifier, so agents that act on untrusted data should still confirm consequential actions.

For agents that act on untrusted data, model: xantly/auto-safety adds a second layer after the model: every tool call the model proposes is checked against the user's original task by a separate model that never sees the tool output, and a call that does not serve the task is stripped from the response with an explanation rather than executed. Streamed requests with tools are answered buffered so the calls can be judged whole. The verdict is in x-xantly-alignment, and the judge's tokens are billed to your organization like any other routed usage. See Chat Completions.

Certifications

SOC 2 Type II, in progress. Xantly is actively pursuing SOC 2 Type II certification. It does not yet hold the certification. The audit report will be published once available.

Learn more

• Security overview, current security posture
• Data Processing Agreement, sub-processors, SCCs, breach terms
• Authentication, tokens, key handling, and best practices
• Bring your own key, route through your own provider keys