How Chrysent keeps your AI traffic, data, and agent actions under control.

Trust boundaries

The platform enforces five separations:

• Customer model-provider credentials are isolated from Chrysent internal or evaluation credentials.
• Operational telemetry is separated from administrative audit and retained inference content.
• Canonical evidence is separated from rebuildable search and replay projections.
• Organization membership is separated from Chrysent infrastructure access.
• Content visibility is separated from the mere existence of retained encrypted content.

Identity and access

The organization is the primary customer isolation and ownership boundary. A platform principal is either a human or a service account, never both. A human or service account belongs to an organization through a membership that carries one of three roles:

• Owner. Controls organization lifecycle, ownership, billing-sensitive actions, and high-impact delegation. An active organization retains at least one Owner except during a defined deletion workflow.
• Admin. Manages ordinary membership, service accounts, routes, policies, retention, and operational incident controls within granted authority.
• User. Consumes granted capabilities and views only authorized usage or evidence.

Personal Access Tokens (PATs) are revocable credentials bound to a single human or service account. A PAT is not an actor or a role by itself. Administrative login and inference authentication are distinct.

Support access

Chrysent has no standing tenant impersonation path. An organization administrator may create an expiring support grant that gives an authenticated Chrysent support employee temporary organization membership. The effective access is the intersection of: the selected organization role; organization authorization, privacy, and encryption settings; the support grant's explicit scope and expiry; and platform restrictions that prohibit Owner/billing powers, membership administration, credential/key management, retention/deletion changes, unrestricted export, secret disclosure, and self-escalation. Support does not become a named customer user, inherit personal credentials, or create a separate decryption/export path. Customer data remains in the organization account and is not automatically copied into support systems.

Provider credentials and governance

Production customer traffic uses customer-supplied provider credentials. Chrysent does not sell model inference. Plaintext credentials never belong in component snapshots, logs, traces, evidence, debug captures, or semantic projections. Gateway terminates client authentication, forwards client headers to providers by default with only narrow hop-by-hop, credential, framing, and proxy-chain exclusions, and injects the provider credential only after the final provider destination is validated. It never returns provider credentials or sensitive upstream transport metadata to clients.

The credential reference in a route can resolve from any of the following:

• An encrypted customer-controlled vault using per-tenant envelope encryption.
• A customer-controlled short-lived credential source.
• A customer-local secret system in self-hosted profiles.

Gateway routes only to enrolled provider endpoints in the customer-configured provider registry. Provider origins are operator-owned: tenant input cannot alter scheme, authority, or port. Every connection and redirect remains constrained to an approved destination, credentials never cross origins through redirects, and independent egress controls deny metadata, link-local, private/control-plane, and other non-provider destinations unless a separately reviewed profile permits them.

Configuration and policy data

Customer safety customization is bounded data — preset selection, rule parameters and resource lists, extraction mappings for customer tool shapes, stable customer rule identifiers, scoped exclusions with reason and optional expiry, category thresholds and configured dispositions. It cannot perform network or filesystem access, load code, inspect platform secrets, call arbitrary host functions, or execute native or WASM plugins.

Evidence

Evidence is a correlated record of observations, decisions, transformations, execution outcomes, configuration context, and declared gaps. It is not merely application logging.

Chrysent records the following evidence record types across all components:

• Evidence logs (correlated observations and outcomes).
• Usage events (per-request attribution).
• Cost events (per-request spend attribution).
• Access events (administrative and support-grant access).
• Security decisions (Touchstone allow / deny / redact / unavailable and Bastion allow / deny / human-review / unavailable).
• Processing results (Gateway transformation outcomes).
• Content transformations (Touchstone redactions and rewrites).
• Observed tool-execution outcomes reported after Bastion's pre-execution decision.
• Administrative audit events (configuration changes, role grants).

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.

Failure handling

Bastion or Touchstone unavailability produces an explicit "unavailable" or "incomplete" result rather than "allow". A pre-authorized tenant disposition may release selected low-risk work under fail-open while disabling or failing closed for sensitive workloads; evidence records the release as a safety bypass, not a successful evaluation.

Configuration and rollout

Configuration activation pins one component snapshot per Gateway, Bastion, or Touchstone operation. The end-to-end interaction records the complete version set used. Production rollouts use a 15-minute binary drain bound. Security-critical authorization, support-grant expiry, credential and route revocation, and emergency shutdown have explicit freshness behavior and cannot remain accepted under a stale last-known-good snapshot.

Coverage and its limits

Every replay should state what Chrysent observed and retained. The absence of an event is not proof that an action did not occur outside an integrated enforcement boundary.

Compliance posture