Encryption and transport security

Encryption claims in Ethen must be tied to a specific transport, store, or provider boundary. The current repository includes a global Content Security Policy configuration, server-only modules, and environment-readiness checks, but it does not establish universal encryption at rest or customer-managed encryption keys.

Use this page to separate the protections that can be reviewed in the application from controls that belong to the deployment platform, database, storage service, external provider, or customer network. Every statement remains subject to security review because the manifest’s generally available label is broader than the verified implementation.

Transport security

Transport security protects data while it moves between a browser, Ethen server, local runtime, database, or external provider. A global CSP in next.config.ts constrains browser resource loading and can reduce some classes of client-side injection or unintended connection. CSP is not a substitute for authenticated requests or encrypted network transport.

The deployed environment should terminate HTTPS for public routes and use secure transport to databases and hosted providers. No universal TLS version, cipher policy, certificate-management process, or connector transport requirement is documented; verify those details in the hosting and provider configuration.

Local and Desktop paths require extra care. An endpoint labeled configured can refer to another machine rather than localhost. Before sending files or prompts, confirm the endpoint’s host, network path, authentication, and operator. Calling a model “local” does not prove that every byte remains on the current device.

Review each network hop

A browser request can pass through a public edge, an application server, a database connection, and an external provider before a result returns. Each hop needs its own transport assessment. The public origin should use HTTPS, but that does not reveal how the application connects to Supabase, a queue, a local runtime, or a provider API.

For the browser-to-Ethen hop, inspect the deployed origin, redirect behavior, cookie attributes, CSP, and any mixed-content warnings. For server-to-database traffic, verify the managed service connection configuration rather than assuming it from a server-only import. For provider calls, confirm the destination host and provider account. For a local runtime, verify whether the endpoint uses loopback, a trusted local network, or a remote address.

Transport review also includes metadata leakage. URLs, headers, error bodies, and proxy logs can expose identifiers or configuration even when the payload is encrypted. Do not place credentials in query strings, and avoid returning provider error bodies without redaction when they can contain account information.

A connector or bridge can add another hop. The current documentation cannot impose one universal transport policy on every external integration, so the integration owner should record the endpoint, authentication method, and network boundary before production use.

Transport failure should remain distinguishable from authentication or provider entitlement failure. Do not disable certificate checks or move a request to an unreviewed endpoint merely to restore connectivity. Preserve the destination, error, and time so the network owner can correct the approved path.

Encryption at rest

Encryption at rest concerns stored data rather than data in transit. Ethen can write to Supabase-oriented stores, product-specific files, memory-only stores, browser state, local runtime storage, and external providers. One statement cannot accurately describe all of those locations.

No platform-wide at-rest encryption contract is currently documented. A managed database or cloud provider may encrypt its underlying storage, but that provider behavior must be confirmed for the customer’s account and region. Local files and development fixtures may follow the host operating system rather than a centralized storage policy.

When reviewing a store, identify the storage owner, physical or managed service, encryption setting, access path, backup treatment, and deletion behavior. Do not infer at-rest protection from a TypeScript type, migration, environment variable, or server-only import.

Storage-specific verification

For Supabase-backed data, confirm the production project, region, database and storage configuration, service-role access, backups, and provider documentation for the customer account. Repository readiness helpers do not expose those operational settings.

For local files, determine which operating-system account owns the directory and whether full-disk or file-level encryption is enabled. For browser storage, assume the signed-in device user can reach the data unless the application adds a stronger boundary. For memory-only stores, encryption at rest may not apply, but process dumps, swap, and logs can still create copies.

External providers require a separate review. Ethen cannot use an application statement to guarantee how a model, media, voice, or connector provider encrypts retained data. The provider’s current account settings and approved terms remain the relevant source.

Key management

Encryption keys, provider credentials, Gateway API keys, user session tokens, and environment variables serve different purposes. BYOK supplies a provider credential; it does not give the customer control over Ethen’s database encryption keys.

A complete key-management program would define generation, storage, access, rotation, revocation, backup, recovery, separation of duties, and audit. Those controls are not established as a unified Ethen service. The current environment helper detects configuration quality, while product modules represent credentials for specific routes.

Do not publish claims about customer-managed encryption keys, a dedicated KMS, hardware security modules, rotation schedules, or key-custodian roles without implementation and policy evidence. Administrators should instead document which secret protects which boundary and who can revoke it.

Secret and key inventory

Maintain separate inventory entries for Ethen-issued API keys, provider credentials, identity-provider secrets, Supabase service values, webhook secrets, session-signing material, and any infrastructure encryption keys. For each entry, record the issuer, purpose, storage location, permitted readers, rotation owner, revocation method, and affected routes.

This inventory exposes dangerous coupling. If one provider credential is reused by Gateway, Voice, and Studio, rotating it can interrupt three products and a compromise reaches all three. If a public environment variable contains a server credential, no rotation schedule can repair the exposure without moving the value to the correct boundary.

A customer-managed encryption-key claim would require more than an inventory. It would need a supported key service, ownership model, encryption integration, rotation behavior, recovery procedure, and product coverage. Those capabilities are not established.

Provider boundaries

Hosted providers control the encryption and transport behavior inside their services. Ethen may select a provider and send a request using a customer or platform credential, but that path does not establish the provider’s at-rest encryption, data retention, training policy, or regional processing.

Provider access should be assessed at three points: the Ethen route, the network request, and the provider account. Verify that the route sends only necessary fields, that the credential belongs to the intended account, and that the provider service is configured for the required data class.

Fallbacks can change the destination. If a product can route to another provider, the approval and data-handling review should cover every eligible provider rather than only the preferred one. No universal fallback or transport policy is proven across all Ethen products.

Provider changes should trigger a fresh transport and storage review. A new provider can introduce a different endpoint, region, credential model, logging path, or fallback destination. Confirm the configured route with non-sensitive input and update the approved provider inventory before sending production data.

If a provider connection fails, avoid disabling certificate verification or moving secrets into client-visible configuration as a workaround. Correct the endpoint, account, or deployment boundary instead.

Customer controls

Customers can strengthen the effective boundary through deployment and configuration choices:

• terminate public traffic through an approved HTTPS configuration;
• keep server credentials out of public environment variables and client bundles;
• review database, object-storage, backup, and local-file encryption settings;
• restrict who can change environment values or provider credentials;
• verify local runtime endpoints before submitting sensitive files;
• document which external providers are allowed for each data class;
• revoke credentials promptly when ownership or risk changes.

CSP reports, provider dashboards, host configuration, and database settings may provide useful evidence, but they should be reviewed alongside application authorization. Encryption cannot compensate for a route that lets the wrong identity read a record.

Deployment verification record

For each production deployment, retain a short verification record that names the public origin, TLS termination owner, Supabase or database endpoint, object-storage provider, backup service, external model or media providers, local runtime endpoints, and secret-management mechanism. Attach the date and reviewer rather than copying credentials or certificates into the document.

Revisit the record after host migration, provider change, new connector, or local-runtime configuration. These changes can introduce a network or storage boundary that was absent from the earlier review.

Where a control is provided by the hosting or database service, link the internal deployment record to that service’s approved configuration evidence. Do not convert a service-specific setting into a universal Ethen feature statement.

Limitations

Broad platform-wide encryption claims, including claims of universal at-rest protection with customer-controlled keys, are unsupported. A formal transport baseline is also absent for connectors, providers, local runtimes, and deployments.

Treat encryption as a set of verifiable boundaries. Record the route, store, provider, endpoint, and control owner. Where the boundary is unknown, classify it as unverified and avoid production use for data that requires an approved encryption contract.

The Privacy Policy and Terms of Service are the approved legal references. Pending security and enterprise-security policy pages are not live authority.

Security reviewers should document unresolved controls as deployment conditions. For example: “production use requires verified HTTPS termination, reviewed Supabase transport, approved provider destinations, and at-rest encryption evidence for each durable store.” That statement is specific and testable without asserting a platform-wide guarantee.

Do not convert a hosting provider’s default into an Ethen commitment unless the deployment contract fixes that provider and setting. Defaults can change, local deployments can differ, and customer-managed infrastructure may use another path entirely.

The same review applies after a change in hosting, database, provider, or local endpoint. Encryption posture is configuration dependent, so an earlier conclusion should not be carried forward automatically.

Any future assurance must identify the covered stores, deployments, providers, and exceptions.