Compliant Mode

Enterprise data protection for regulated workloads: route only to a verified model catalog on certified platforms (SOC 2, ISO 27001, HIPAA BAA), with zero data retention, region pinning, and a tamper-evident audit trail.

Enterprise data protection for AI inference. Your traffic routes only to a verified catalog of models on certified cloud platforms, with zero data retention inside Xantly, region pinning, and a tamper-evident audit trail.

What it is

Compliant Mode is a per-organization control for regulated and security-sensitive workloads. When it is enabled for your organization, every request from your account routes only to a verified catalog of models, each one served through a platform that holds the certifications your agreement requires. Anything outside that catalog is rejected before it reaches a provider.

The verified catalog is delivered across certified cloud platforms (Amazon Bedrock, Google Vertex AI, Azure OpenAI) plus named direct-from-provider exceptions. You get the same data-protection terms you would obtain from a direct agreement with each platform, with the added benefit of routing across many models for cost efficiency, all inside the boundary you approved.

Enterprise feature. Compliant Mode is provisioned by Xantly under a written agreement. Talk to us at [email protected] to enable it for your organization.

How it differs from regular auto mode

Both modes use the same model: "auto" call and the same OpenAI-compatible API. The difference is what auto is allowed to pick.

	Regular auto mode	Compliant Mode
Model pool	10,000+ models across every provider	Only your organization's approved catalog on certified platforms
Selection	Best model for the task, cost, and latency	Best model for the task, cost, and latency, within the approved catalog
Out-of-catalog request	Served	Rejected with a clear error
Data retention	Standard tiered retention (configurable)	Zero retention: nothing is written to logs, cache, or storage
Region	Routed for performance and cost	Pinned to the regions in your agreement
Audit	Standard usage records	Tamper-evident, per-request evidence of every model served

In short: regular auto optimizes across everything; Compliant Mode optimizes across the subset you have verified and contracted, and guarantees your traffic never leaves it.

How to use it

There is no code change, no new header, and no request parameter. Once Compliant Mode is enabled for your organization, your existing API keys carry the policy automatically.

curl https://api.xantly.com/v1/chat/completions \
  -H "Authorization: Bearer $XANTLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "auto", "messages": [{"role": "user", "content": "Summarize this contract clause."}]}'

model: "auto" routes across your approved catalog and returns the best fit inside it.
An explicit approved model (for example a model slug from your agreement) is served directly.
A model outside your catalog returns 403 with code: "compliance_policy_violation", before any content leaves your environment.

This is the entire integration. If your application already calls Xantly, it works under Compliant Mode with no changes.

Is it on by default? Compliant Mode is not on for every account. It is enabled per organization when your agreement is signed. Once enabled, it is the default for all of that organization's traffic, on every key, with no per-request opt-in.

What routing to an out-of-catalog model returns

{
  "error": {
    "message": "Model 'gpt-x' is not in your organization's compliant model catalog. Compliant Mode is enabled for your organization; use 'auto' or a model from your approved catalog.",
    "type": "permission_error",
    "code": "compliance_policy_violation",
    "param": "model"
  }
}

If an approved model's platform is momentarily unavailable, you receive a 503 instead, and the request is never quietly rerouted to a model outside your catalog. Compliant Mode never substitutes or falls back beyond the approved set.

What you get

Guarantee	What it means
Model allowlist enforcement	Traffic routes only to the models named in your agreement, enforced server-side in the router. A request to any other model is rejected before it leaves your environment.
Zero data retention	Your prompts and responses are never retained by Xantly. Each request is processed in memory and the result is returned, with nothing written to logs, cache, or storage.
Data residency	Inference is processed in the region you select, and your data stays within it.
Certified platforms	Every model is served through infrastructure certified to SOC 2 Type II and ISO/IEC 27001, with GDPR processing and a HIPAA Business Associate Agreement available.
Access controls and audit trail	Enterprise single sign-on, role-based access control, and a complete, tamper-evident record of every action on your account.
Sub-processor transparency	A current, versioned list of every sub-processor in your data path, with advance notice before any change.

Certifications are held by the cloud platforms through which Xantly delivers the models. Your agreement names the exact platforms, models, and regions.

Per-request controls

Under Compliant Mode, per-request options may only make a request more restrictive, never less. For example, x-xantly-no-store and the cache-control headers documented in Intelligence Modes continue to work as tighten-only controls. Nothing in a request can widen your organization's approved catalog, relax retention, or change the region.

Verifying compliance

Every request served under Compliant Mode is stamped with the policy version that governed it, so your team and ours can confirm, in one query, that every request in a period was served by an in-catalog model and that no data left the agreed boundary. The current sub-processor list is available at:

curl https://api.xantly.com/v1/compliance/sub-processors \
  -H "Authorization: Bearer $XANTLY_API_KEY"

Access controls run through enterprise single sign-on, and every administrative action is recorded in an append-only, tamper-evident audit trail that your team can independently verify.

Frequently asked questions

Do I have to change my code?

No. Compliant Mode is enabled on your organization by Xantly. Your existing API keys and your existing model: "auto" calls work unchanged, now constrained to your approved catalog.

Is Compliant Mode a request parameter I set?

No. There is deliberately no compliant_mode flag or header. Making compliance a per-request option would mean a single mistaken request could send data outside the boundary. Instead it is an account-level policy that every key inherits, so it cannot be forgotten or bypassed on any single call.

How does `auto` behave under Compliant Mode?

Exactly as it does normally, task analysis and cost-and-latency-aware selection, except the candidate pool is your approved catalog rather than the full 10,000+ model catalog. You still get automatic model selection and failover, contained within the verified set.

What happens if I request a model that is not approved?

The request is rejected with a 403 and code: compliance_policy_violation before any content is sent to a provider. Approved models whose platform is briefly unavailable return a 503 with no fallback outside the catalog.

Which models and regions are in my catalog?

The exact models, platforms, and regions are defined in your Compliant Mode agreement and can be extended by contacting your account team. The live sub-processor list is available from the endpoint above.

Does Compliant Mode change pricing?

You pay the model's provider list price routed through Xantly. Routing across the verified catalog commonly reduces inference spend while staying inside the approved set.

What's next

Intelligent Routing: how model: "auto" analyzes a request and selects a model
Intelligence Modes: proxy, cache, and full pipeline control, and the tighten-only cache headers
Authentication: API keys, tokens, and access controls