Security at Xalorra

This page describes Xalorra’s security approach and the controls we design around. It’s written to be readable by engineering teams and procurement alike: concrete boundaries over vague promises.

Xalorra is a backend-first control plane for lakehouse operations and versioned ML workflows, built around tenant boundaries, stable HTTP contracts, and traceable runs. That design choice is security relevant: when operations are explicit and versioned, it becomes easier to audit, review, and control data access.

Note: Xalorra is in Public Beta. Core constraints (tenant isolation, contracts, artifacts, lineage) are stable by design; some features and integrations evolve over time.

Security is shared between Xalorra and our customers. We secure the platform and its operational boundaries; customers secure their environment, users, and inputs.

Tenant isolation is not a feature checkbox. It’s the core design constraint. Xalorra scopes platform operations to a tenant boundary and uses explicit identifiers (tenant + namespace) to reduce accidental cross-tenant access.

• Tenant-aware routing and request context scoping.
• Namespace boundaries for datasets, runs, artifacts, and versioned outputs.
• Operational metadata (lineage/traces) tied to tenant-scoped identifiers.

In practice, this means “who can see what” is not implied. It’s anchored to tenant boundaries and the artifacts produced within those boundaries.

We design for protecting both personal data and Customer Content. Security controls typically include encryption in transit and appropriate encryption at rest depending on your deployment and storage configuration.

We encourage data minimization: store only what you need, keep retention explicit, and avoid placing secrets or high-risk personal data into fields that do not require it.

Xalorra is designed to support least-privilege access patterns and clear authorization boundaries at the tenant level. Customers should manage user onboarding, role assignments, and access reviews.

• Prefer organization-scoped access with explicit tenant selection.
• Use separate environments (dev/staging/prod) where applicable.
• Review access regularly, especially for operators and admin roles.

If you need procurement-ready access model details for your deployment, contact security@xalorra.com.

Xalorra does not aim to be your secret manager. Instead, we encourage strict key hygiene and explicit boundaries:

• Store API keys and credentials in a dedicated secret store in your environment where possible.
• Rotate external provider keys regularly (especially GenAI provider keys).
• Avoid embedding secrets in datasets, prompts, or job configurations.

When GenAI is enabled, customers commonly use “bring-your-own-key” patterns and restrict which users can configure provider routing.

Auditability is a security feature. Xalorra is built around traceable runs and versioned artifacts to help teams answer the hard questions later: what ran, on which data, with which version, and what output was produced.

Customers control what they choose to log and how long they retain it. For sensitive environments, reduce payload logging and focus on metadata necessary for governance.

Xalorra is not a hosted foundation model provider. GenAI workflows operate through a gateway pattern: your selected model provider runs outside; Xalorra focuses on context assembly, routing, and traceable runs.

External model providers apply their own data handling policies. Customers should choose providers and settings aligned to their compliance and privacy requirements.

We treat vulnerability management as an operational routine, not a crisis ritual. Reports are triaged based on severity and exploitability, then remediated with appropriate urgency.

• We prioritize issues that affect tenant boundary integrity and data exposure risk.
• We aim for minimal, targeted fixes that preserve stable contracts and artifacts.
• We coordinate disclosures to reduce customer risk when patches are available.

If you discover a vulnerability, follow the responsible disclosure guidance below.

We maintain an incident response process designed to contain impact, restore service, and learn from failures. When appropriate, we notify affected customers with practical details: what happened, what data was implicated, what we changed, and what customers should do next.

• Identify and contain suspicious activity.
• Preserve relevant logs for investigation.
• Remediate root cause and validate the fix.
• Communicate clearly to customers when material impact is confirmed.

Continuity depends heavily on how you deploy Xalorra (self-hosted, on-prem, cloud). Customers should implement backups and recovery plans for their environment, including datasets, artifacts, and configuration state.

For enterprise deployments, we can discuss recommended backup scopes and recovery workflows during an onboarding or architecture review.

Security improves when customers have explicit levers. Typical controls include:

• Access governance: which users can read datasets, run pipelines, and change routing.
• Retention choices: what to log, what to keep, and for how long.
• Provider routing boundaries (GenAI): which providers are allowed and by whom.
• Environment separation: dev/staging/prod with explicit promotion workflows (where applicable).

If your environment has strict requirements, we recommend an architecture review early—before teams build accidental dependencies into the workflow.

If you believe you found a security vulnerability, please report it privately to security@xalorra.com.

Include: a clear description, steps to reproduce, affected endpoints/components, potential impact, and any proof-of-concept details. Please avoid public disclosure until we have a reasonable chance to investigate and patch.

We appreciate reports that respect customer safety: minimal data exposure, no destructive actions, and no exfiltration beyond what is necessary to demonstrate impact.

Security inquiries: security@xalorra.com.

For enterprise evaluation, architecture review, or procurement: use the CTAs below. We keep it direct: tenant isolation, traceability, provider routing boundaries, and operational controls.