Incident response and vulnerability reporting

Incident response coordinates detection, containment, investigation, recovery, and review when Ethen or a connected provider may be operating outside the expected security boundary. Vulnerability reporting concerns a potentially exploitable weakness and may occur before an incident.

Ethen currently exposes public Help and Contact routes and safe-error patterns, but no approved 24/7 incident process, dedicated vulnerability intake, severity SLA, or disclosure timeline is established. The lifecycle below is a conservative operating guide, not a contractual commitment.

Incident lifecycle

Start by recording what was observed, when it began, which product or route is affected, and whether the issue is still active. Assign an internal owner and preserve request IDs, trace IDs, error codes, provider identifiers, and relevant configuration state.

Classify the immediate risk: credential exposure, unauthorized access, data disclosure, provider misuse, unavailable service, incorrect policy enforcement, or loss of evidence. The classification guides containment but should remain open to revision as facts change.

Proceed through containment, investigation, recovery, and post-incident review. Do not erase logs or rotate every credential indiscriminately before preserving the information needed to understand the event.

Initial severity without an SLA

A customer can use an internal severity model even though Ethen does not publish one. Evaluate whether data or credentials may be exposed, whether unauthorized activity is continuing, how many users or projects are affected, whether an external provider is involved, and whether a safety or legal obligation may apply.

The severity label should guide the customer’s own response, not imply an Ethen response commitment. Update it as evidence changes. A provider outage that blocks one optional route is different from a leaked credential that can be used outside Ethen.

Maintain a timeline from the first observation. Record decisions as they occur instead of reconstructing them only after recovery.

Evidence preservation

Preserve the original error, request and trace identifiers, affected configuration, relevant logs, and provider account records before making broad changes. Copy only the information needed for the investigation and record its source.

Do not preserve raw credentials. If a secret is part of the incident, record its type and safe identifier, then revoke it through the issuer. Evidence preservation should not delay immediate containment when continued use creates material risk.

Decision log

Keep a short decision log alongside the timeline. Each entry should state the decision, available evidence, owner, expected result, and time for reassessment. This is especially useful when a provider or backend is unavailable and the team must choose between continued operation and a broader shutdown.

The log does not need to be an Ethen feature. It provides accountability while the formal incident process remains under review.

Customer reporting

Customers can use /help or /contact for product assistance. Include the affected product, approximate time, route, request or trace identifiers, visible error, and a concise description of impact.

Do not include raw API keys, provider credentials, session tokens, or unrelated personal data. If a provider account is involved, contact that provider through its approved channel as well.

The public routes do not establish guaranteed response times, severity handling, or continuous monitoring. Customers with an urgent production incident should follow their own approved incident plan while seeking Ethen assistance.

Information to prepare

A useful report contains:

• affected product and route;
• environment or deployment;
• first and most recent observed time;
• visible impact;
• request, trace, run, or provider identifiers;
• exact error code or state label;
• whether a credential, personal data, or repository content may be involved;
• containment already performed;
• a safe way to reproduce the issue, if appropriate.

Remove raw secrets and unrelated customer content. If a screenshot is necessary, redact values before attaching it.

The customer should keep its own incident record because the Help and Contact routes do not guarantee a durable case-management or evidence system.

Coordinating multiple parties

An incident can cross Ethen, a hosting provider, Supabase, an identity provider, and a model or connector provider. Assign one internal coordinator to track which party owns each question and to align identifiers and timestamps across records.

Do not assume that contacting one party notifies the others. Provider credential misuse, for example, may require provider-side revocation while Ethen investigates how the key was stored or routed.

Vulnerability reporting

A vulnerability report should describe the affected component, preconditions, observed behavior, potential impact, and safe reproduction steps. Avoid testing systems or repositories without authorization, accessing other users’ data, or performing destructive actions.

No dedicated vulnerability email, form, bug bounty, or disclosure SLA is verified. Use the approved Contact route and provide only enough detail to establish the issue until a secure exchange method is agreed.

A product bug, configuration error, provider outage, and vulnerability are different categories. Clear classification helps route the report without overstating impact.

Safe reproduction boundary

Demonstrate the issue with the minimum access and data needed. Use an account, project, or repository you own or are authorized to assess. Stop if reproduction would access another user’s information, alter a production resource, test credentials, create uncontrolled provider cost, or degrade service.

Describe expected versus observed behavior and the security consequence. Include code snippets or request fields only when they do not expose secrets. A proof of concept should establish the flaw without becoming an exploitation guide.

If a secure channel is needed for additional details, request one through Contact. Do not invent an address or assume encrypted attachment handling.

Scope and ownership

State whether the report affects the Ethen application, a deployment configuration, an external provider, or an integration between them. This distinction helps avoid asking Ethen to remediate a provider account issue or asking a provider to fix an application authorization flaw.

If several components contribute, describe the interaction and keep separate evidence for each boundary.

Containment

Containment limits further harm while preserving evidence. Actions can include revoking an exposed credential, disabling a provider route, removing unauthorized access, pausing a workflow, isolating a local runtime, or blocking a specific operation through available policy controls.

Choose the narrowest action that controls the risk. A broad shutdown can create additional operational impact and may destroy useful state. Record each containment action, the person who authorized it, and the expected reversal condition.

Ethen does not currently document automated cross-product containment or a centralized incident console.

Containment choices by incident type

Choose actions supported by the product and external service. No centralized one-click containment is documented.

Recovery criteria

Define recovery before restoring the affected path. Criteria can include a revoked or replaced credential, verified route authorization, corrected provider selection, successful low-risk test, and restored evidence collection.

Resume in stages where possible. A successful test should confirm the boundary that failed rather than only showing that another provider or fallback produced a response.

Communication

Communication should separate confirmed facts from hypotheses. State the affected capability, customer impact, current containment, and next decision. Avoid publishing internal secrets, speculative root causes, or provider claims that have not been confirmed.

External notification duties depend on law, contract, data type, and jurisdiction. This documentation cannot determine those obligations. Privacy and legal reviewers should approve customer or public statements when personal or regulated data may be involved.

No uptime, notification, or update cadence is promised by the current status and contact routes.

Status language

Use plain states: investigating, contained, recovering, monitoring, or closed. Explain the customer-visible effect and the next decision. Avoid promising a resolution time when the cause or external dependency is unknown.

When an external provider is involved, distinguish what Ethen has confirmed from what the provider has confirmed. Do not attribute provider retention, training, or security behavior without an authoritative statement.

A public update, legal notification, customer-specific message, and internal engineering note have different audiences. Route them through the organization’s approved review process.

Customer-facing statements should identify the affected Ethen capability without implying impact to unrelated products. If only a BYOK provider route failed, avoid describing the entire platform as unavailable. If scope is unknown, say that investigation is continuing.

Correct earlier statements when new evidence changes the assessment. Accuracy is more important than preserving the first hypothesis.

Keep an internal record of who approved each external statement and which facts were still unverified at publication time. That distinction helps later corrections remain transparent and prevents an early hypothesis from becoming the permanent incident narrative.

Post-incident review

After recovery, document the timeline, root or contributing causes, affected data and systems, evidence gaps, containment, recovery tests, and corrective actions. Assign owners and completion criteria for each action.

Review whether authentication, route authorization, provider configuration, credential handling, policy enforcement, logging, retention, or support procedures contributed to the incident. A missing trace or sample-only audit view is itself a finding when it delayed investigation.

The final review should distinguish changes already implemented from planned work. It should not claim formal assurance or certification based solely on closing the incident.

Corrective-action categories

Group actions by control area: identity and authorization, credential storage, provider routing, data minimization, policy enforcement, observability, retention, documentation, and operating procedure. This helps prevent a narrow code fix from leaving the surrounding process unchanged.

For each action, identify an owner, deadline, verification method, and whether the change is code, infrastructure, provider configuration, or policy. Re-test the original failure path with safe data.

The review can improve readiness, but it is not a penetration test, external audit, or compliance attestation.

Verification of corrective work

Close a corrective action only after testing the original failure path or a safe equivalent. A documentation change alone cannot verify route authorization, and a successful request cannot verify audit retention.

Record the test, expected result, actual result, and remaining uncertainty. Keep unresolved infrastructure or policy decisions as open blockers rather than marking the incident program mature.

Lessons for documentation

An incident may reveal that a state label, setup guide, error message, or troubleshooting step was ambiguous. Update the owning page with the verified boundary and remove any wording that suggested an unsupported guarantee.

Documentation corrections should cite the implemented behavior and remain draft when infrastructure or legal approval is still pending.

Track whether corrective actions depend on external setup such as Supabase, identity bridging, provider policy, or durable audit ingestion. An action cannot be marked complete solely because the repository contains a planned schema or interface.