Security overview

Ethen’s security posture is defined by the controls that are visible in the current platform, the boundaries those controls actually enforce, and the work that still depends on production configuration or policy approval. Use this page to orient an architecture or security review before evaluating authentication, credentials, data handling, approvals, audit records, or enterprise administration in detail.

The manifest classifies this page as generally available, but the implementation evidence supports a more cautious reading. Authentication can be optional, audit data is currently sample based, several persistence and identity decisions remain open, and no compliance certification is asserted. Treat the material below as a current operational map rather than an attestation.

Security model

Ethen’s current model combines application controls, server-side configuration checks, product-specific policy decisions, and explicit customer configuration. No single repository component establishes a complete security program for every route and product.

At the application boundary, app/layout.tsx conditionally enables Clerk when NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY is configured. That integration makes authentication infrastructure available, but it does not prove that every route is protected or that every authenticated identity maps cleanly into Supabase ownership. Route and API authorization still need to be reviewed where sensitive data or actions are involved.

Server-side readiness checks in lib/security/env.ts trim environment values, reject known placeholders, distinguish public and server Supabase readiness, and reject a loopback public Supabase URL during configured checks. These controls help detect unsafe or incomplete configuration. They do not replace managed secret storage, credential rotation, access logging, or a production key-management system.

Product controls add another layer. Gateway, Workflow Agent, and Sentinel use policy, approval, status, and evidence concepts for particular operations. Those concepts are useful, but their presence in one product does not establish platform-wide enforcement.

Control layers

Security decisions should be reviewed by layer because each layer answers a different question.

A mature review follows a request through all applicable layers. For example, enabling authentication at the root is only the first step; the reviewer must also confirm route ownership, server authorization, data access, provider selection, and the evidence produced by the operation.

A control review should also distinguish prevention from detection. Input validation and authorization can prevent an operation; logs and alerts can only reveal what occurred after the fact. The current platform contains examples of both, but no single control catalog proves that each sensitive route has a preventive check and a durable detective record. Reviewers should map the specific action to its validation, authorization, policy decision, provider boundary, and stored evidence.

Failure behavior deserves the same attention as the normal path. lib/security/errors.ts supports safer error handling patterns, but a safe error message does not confirm that an action was rolled back or that no partial external request occurred. Confirm the side effects of failed operations in the relevant product.

Customer responsibilities

Customers control several high-impact inputs to the security posture. They decide which users receive access, which credentials are supplied, which external providers receive data, which project routes are used, and whether proposed actions should proceed. They also remain responsible for having authority to submit repository content, files, prompts, personal data, and provider credentials.

Before using a sensitive workflow, identify the data class, the destination, the expected persistence, and the person accountable for the decision. Avoid placing a production secret in a client-visible variable. Keep provider credentials separate from Ethen Gateway API keys, and do not treat a configured environment variable as proof that the value is encrypted or centrally managed.

Customers should also verify product maturity at the capability level. “Preview,” “Private Alpha,” “Sample,” “Fixture,” “Demo-only,” “Setup required,” and “Unavailable” describe materially different operating states. A control shown in a preview surface may support evaluation without supporting durable production use.

Operational evidence

Operational evidence can include request identifiers, policy outcomes, approval records, run receipts, trace fragments, configuration state, and product-specific logs. The usefulness of each record depends on its source and persistence model.

The /audit-log surface is explicitly labeled Private Alpha and Sample, and its entries come from fixtures. Those records are suitable for understanding the intended shape of an audit experience, not for proving that a production event was ingested or retained. Observability may similarly label information as bridged, fixture, or unavailable.

When assessing an event, record where the evidence came from, whether it is durable, and which subsystem produced it. A screenshot of a sample table should not be treated as an immutable audit record. Likewise, a schema or type can document an intended field without proving that every runtime writes it.

For an evidence review, start from a known action rather than from a dashboard. Identify the expected record, locate the actual source, and compare the state shown by the product with the state stored by the backend. If the record comes from a fixture or bridge, label that fact in the review. If the runtime exposes no trace, token, provider-attempt, or approval record, document the gap instead of creating a substitute from assumptions.

Operational evidence is strongest when it carries a stable owner and correlation identifiers. Without those attributes, two events that look similar in the interface may not be distinguishable during an investigation.

Policies

Ethen products use decision terms such as allow, deny, requires_approval, human_required, and blocked. These values describe how a particular subsystem can classify an operation. Their exact scope depends on the product and route.

A policy should be read together with its enforcement point. The important questions are: what input is evaluated, when the decision is made, what happens after a denial, whether an approval can change the outcome, and what evidence is retained. Platform-wide coverage, centralized exceptions, and immutable decision history are not established.

Use /policies to inspect the current policy surface and /approvals to review the current approval experience. Do not infer durable enforcement or separation of duties solely from those routes.

Where to begin

Start with the boundary that creates the greatest risk for your use case.

• For identity and route protection, continue to Authentication and access control.
• For prompts, files, credentials, logs, and provider requests, read Data handling.
• For secret lifecycle and provider credentials, use Credential management and BYOK security and operations.
• For decisions that can block or require review, read Policies and enforcement and Approval governance.
• For current audit limitations, read Evidence and audit logs.

Legal statements remain governed by the Privacy Policy and Terms of Service. This documentation explains current operational behavior and known gaps; it does not certify the platform against a compliance framework.