Data handling

Ethen handles different kinds of information across model access, workflows, creative tools, voice, security review, local runtimes, and platform operations. This page provides a practical inventory of the categories visible in the current implementation and explains how to reason about processing, storage, access, and external providers.

It is not a complete data map or subprocessor register. Product-specific persistence differs, production Supabase configuration is not proven by repository files, and external provider policies remain separate. Use the categories below to prepare a deployment-specific review and consult the Privacy Policy for authoritative privacy statements.

Data categories

The platform can encounter several distinct data classes. Keeping them separate matters because their access, destination, and persistence may differ.

A single interaction may cross several categories. A prompt can produce a provider request, output, usage event, error record, and trace fragment. Review the full path rather than classifying only the initial input.

Follow one record through the platform

Consider a model request submitted from a project surface. The input may contain account context, a project identifier, prompt text, attached file content, a selected model, and routing preferences. Server processing can create a provider request, an authorization or policy decision, usage metadata, a response, and an error or trace record. The provider can create its own account-level logs and retained service data.

That example illustrates why “prompt data” is too narrow a category for a handling review. The same operation can create identity, content, secret-adjacent, operational, and governance records. Each copy can have a different owner and deletion path.

A Sentinel review creates a different chain. Repository paths and source excerpts can become findings, evidence references, review status, and patch-proposal content. The product’s read-only boundary prevents source modification, but the review records can still contain sensitive code or infrastructure details.

A Local Chat interaction may avoid a hosted model provider, yet file context and prompts still travel to the configured runtime endpoint. Verify whether that endpoint is on the current machine before classifying the interaction as device-local.

Processing

Processing begins when an Ethen surface accepts an input and continues through validation, policy checks, provider routing, local execution, storage, or rendering. The exact path depends on the product.

Server-side modules should handle provider credentials and other sensitive configuration. Input validation can reject unsupported or unsafe values before an external request is attempted. Product-specific policy decisions may allow, deny, block, or require approval for a proposed action. These controls are not uniform across every route, so a deployment review should identify which checks run for the operation being assessed.

External processing occurs when data is sent to a hosted model, media, voice, connector, or other provider. Local and Desktop paths can reduce external transfer when the selected runtime is genuinely local, but a configured endpoint may point to another machine. “Local” should therefore be verified from the endpoint and runtime, not inferred from the product label.

The platform should avoid adding unnecessary fields to provider requests. No general statement about provider retention, training, or geographic location can be made from the repository alone.

A useful processing review traces one concrete operation from input to output. For a Gateway request, that may include key validation, model or provider selection, policy and budget checks, an external provider call, response serialization, usage accounting, and log creation. For Sentinel, the path can involve repository intake, scan planning, findings, evidence, and review without source modification. For Local Chat, the critical distinction is whether the selected endpoint is actually on the same device.

Each step can create a new copy or representation of the original data. Derived content such as embeddings, summaries, thumbnails, redacted logs, or evaluation results should be treated as data in its own right when it is implemented. The current repository does not establish one universal derivation pipeline, so product-specific sources remain authoritative.

Storage

Storage behavior is product and environment specific. Supabase-oriented server modules and migrations indicate an intended durable backend, while some current products use local files, in-memory stores, fixtures, or preview records. Those states should not be collapsed into one storage promise.

Before relying on persistence, determine:

• the store used by the route;
• whether the store is configured in the deployed environment;
• which identifier owns the record;
• whether access control or RLS applies;
• whether the data survives restarts and deployments;
• whether backups cover the store;
• whether deletion reaches copies, backups, and providers.

An environment variable may hold a credential, but that does not make it a managed-secret service. A fixture can populate a table, but that does not make the table a durable audit source. A browser or local-file store can support evaluation while remaining inappropriate for shared production records.

No fixed storage duration is documented across all product families. Retention and deletion must be reviewed separately.

Storage states

Use explicit storage-state labels during review:

• durable — backed by a configured persistent store and expected to survive ordinary restarts;
• local file — stored on a specific machine or development environment;
• memory only — lost when the process ends;
• fixture or sample — supplied for demonstration rather than customer history;
• unavailable — no verified store exists for the record.

These labels prevent a UI table from being mistaken for a durable system of record. They also make migration planning clearer: a feature can be functionally visible while still requiring production persistence, ownership, and deletion work.

Access

Access has at least three layers: access to the interface, permission to call the server route, and authorization to read or change the underlying record. Optional root authentication does not establish all three layers automatically.

Administrators should review sensitive routes individually and confirm that server handlers derive ownership from a trusted identity rather than from an untrusted client value. Where Supabase is used, validate RLS and service-role usage for the actual tables and storage buckets. A schema or migration is not enough to prove complete access control.

Secrets require narrower access than ordinary project data. Raw provider keys should not be returned to the browser after initial handling, included in logs, or copied into user-visible errors. Approval and audit information can also contain sensitive context, such as proposed actions, actor identities, repository paths, and provider metadata.

Access reviews remain an operational responsibility because a complete enterprise role and recertification model is not established.

Access questions by data type

For account and project data, ask which trusted identity owns the record and whether the route validates that ownership. For provider credentials, ask whether the raw value is ever returned after creation and which server process can read it. For audit or evidence data, ask whether reviewers can see sensitive prompts, paths, or provider metadata. For local files, ask whether the configured endpoint leaves the device.

These questions should be answered by the deployed route and store, not by the navigation label. A public-facing page can coexist with protected APIs, and an authenticated page can still query a store incorrectly if ownership is not enforced.

Subprocessors and providers

Hosted providers may receive prompts, outputs, audio, images, files, or connector payloads depending on the selected product. The customer’s provider account and configuration influence who processes the data and under what terms.

A current, complete subprocessor inventory is not included in the repository evidence. Do not infer that every visible provider is enabled or that every provider follows the same retention, training, deletion, security, or regional-processing policy. Availability can also depend on credentials, account entitlements, model access, and provider health.

BYOK changes credential ownership, not the fundamental processing boundary. Ethen still brokers a request to the selected provider, and the provider still applies its own service terms. Supplying a provider key does not create customer-managed encryption or guarantee direct isolation from Ethen’s routing and operational metadata.

When a provider is optional, document the alternative path and the consequence of disabling it. If no configured provider or local runtime can perform the task, the honest state is setup required or unavailable.

Customer controls

Customers can reduce exposure by making deliberate choices before data enters a workflow.

1. Classify the input and remove material that is unnecessary for the task.
2. Confirm that the selected route is authorized for the user and project.
3. Choose a provider or local runtime whose current terms and deployment location meet the use case.
4. Keep Gateway keys, provider credentials, and user session tokens separate.
5. Review policy and approval outcomes before allowing a high-impact action.
6. Verify whether logs, traces, outputs, and artifacts are live, durable, sample, or unavailable.
7. Record the owner of stored data and the process for revoking access or deleting it.

Use /settings, /environment-variables, Gateway configuration surfaces, and product-specific policy pages only as supported control points. Their presence does not replace a deployment-specific data inventory or legal review.

The Privacy Policy governs privacy statements, and the Terms of Service governs account and service responsibilities. Pending retention, BYOK, and security policy routes must not be treated as published commitments.

Data minimization is the most reliable control available before processing starts. Submit only the repository paths, files, prompt context, audio, or media needed for the task. Where the product supports a preview or dry run, use it to inspect the proposed route and data destination before enabling a live provider call.

For recurring workflows, revisit the data path when a provider, credential, runtime endpoint, project owner, or product maturity changes. A previously acceptable configuration can become inappropriate when the destination or persistence model changes.

Review before enabling a new data path

When a new product, provider, connector, or local endpoint is introduced, compare the old and new data paths. Record which fields leave Ethen, which records become durable, who can access them, and what changes in deletion or incident handling. A route that looks similar in the interface can have a materially different external destination or persistence model.

Repeat the review after provider-account, backend, or identity changes. Data-handling approval should follow the actual configured path rather than the product name alone.