Data handling & deployment
What data Chrysent handles
- Session metadata: request timestamps, model identifiers, tenant ID, latency, policy decisions.
- Prompts and responses: recorded when audit or replay is enabled (configurable per tenant).
- Tool-call traces: for proposed calls evaluated by Bastion: the attempted tool, arguments, decision, and reasoning.
- Configuration data: routing rules, policies, model catalogs, and integration credentials (stored encrypted).
Retention modes
Each tenant selects one of three retention modes:
- Minimal evidence. Metadata-only retention — request identifiers, principals, decisions, durations. No prompt or response content retained by default.
- Retained content. Encrypted durable payloads after transient processing. Accessible to authorized principals through replay.
- Semantic projection. Customer-hosted projection after cost and privacy validation. Optional and explicitly scoped per tenant.
Per-tenant retention defaults:
- Audit ledger: configurable per tenant. Default 90 days; longer retention can be configured in the customer environment.
- Prompt/response capture: opt-in. When enabled, retention follows the audit-ledger setting.
- Tool-call traces: same retention as audit ledger.
- Commercial account records: deleted within 30 days of contract termination, with a 60-day grace period for accidental offboarding.
Where data lives
Chrysent sells self-hosted software only. The control plane, audit ledger, and other product software run in customer-owned or customer-controlled infrastructure. Retained product data remains there, supporting data sovereignty and residency requirements.
When a customer configures an external model provider, provider-bound request data is sent from the customer deployment to that third party under the customer's configuration and provider agreement. Chrysent does not host those provider services or operate a separate customer-data tier.
Provider and subprocessor boundaries: Chrysent does not operate customer product deployments or maintain a product-cloud subprocessor tier. Third-party model providers are selected and configured by the customer. The hosted chrysent.ai marketing website and its form and analytics data are separate from customer product deployments.
Who can access your data
- Your team: role-based access per your tenant configuration.
- Chrysent support: only via an expiring support grant you create; scope-limited; time-bound; logged.
- Chrysent engineering: only for customer-initiated support tickets; access is logged and auditable by you.
Chrysent has no standing tenant impersonation path. Effective support access is the intersection of the selected organization role, your authorization settings, the support grant scope and expiry, and platform restrictions that prohibit Owner/billing powers, retention changes, unrestricted export, secret disclosure, and self-escalation.
Deployment profiles
Chrysent sells self-hosted software. The current customer-operated profile and the future air-gap direction change placement, operator responsibility, available capabilities, connectivity, dependencies, and configured failure/retention behavior. They share core contracts and terminology but do not promise identical capability sets or operating behavior.
Customer-operated self-hosted / private cloud
Delivery model: Self-hosted software. Operator: Customer-owned or customer-controlled Kubernetes environment operated by the customer.
The operational control plane is local to the customer environment. Endpoints, storage, and optional local projections are customer-controlled. Retained product data remains in the customer environment, supporting data sovereignty and residency requirements.
Air-gap-capable enterprise
Status: Future direction. Operator: Fully customer-operated disconnected Kubernetes environment.
True air-gap operation cannot depend on public model APIs, remote classifiers, cloud control, or hidden telemetry egress. Air-gap deployment requires only locally reachable or private model endpoints, full operational control local, and offline signed licensing and artifacts. No cloud billing dependency. Entirely customer-hosted and operable without Chrysent network access.
Deployment responsibility checklist
Before deployment, agree with Chrysent who owns each operational responsibility for your environment.
- Who owns the customer-facing incident response runbook for the customer's deployment profile?
- Who owns the customer-facing status page and SLA reporting surface?
- Who owns credential rotation cadence and revocation propagation SLAs?
- Who owns the customer-controlled short-lived credential source in the customer-operated profile?
- Who owns backups of the audit ledger, and what is the recovery time objective?
- Who owns the boundary between air-gap artifacts and online licensing?
- Who owns the on-call schedule for customer-facing support grants?
Questions
For data-handling questions specific to your environment, use /contact/demo and reference “data handling” in the problem field.