Security Statement

Ethen security focuses on protecting accounts, workspace content, secrets, administrative actions, and service integrity. Controls may include authentication, authorization, encryption in transit, secret handling pathways, environment separation where implemented, logging, and operational access discipline. This statement describes intended posture and product direction. Exact control implementations can vary by component and maturity. We avoid claiming certifications, audit outcomes, or test results that are not published as verified facts. Customers should evaluate whether the current posture fits their risk tolerance and industry obligations. Security work is continuous. As features ship, threat models and mitigations are revisited. Public pages are updated when material posture descriptions change, but day-to-day engineering hardening may precede documentation updates.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Upcube is responsible for securing the systems it operates. Customers are responsible for identity lifecycle, member permissions, device security, key management, prompt hygiene, connected-service scopes, and review of high-impact actions. If a customer enables broad admin access, weak passwords, shared credentials, or over-scoped tokens, residual risk increases regardless of platform controls. Providers selected via platform routing or BYOK apply their own security practices to data they process. A practical enterprise checklist includes: MFA for admins, least-privilege roles, key rotation, integration scope review, approval gates for writes, and an offboarding runbook.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Access to Ethen should use individual accounts, strong authentication, and session protections provided by the product and identity stack. Customers should enable available multi-factor authentication and rotate credentials after suspected compromise. Service accounts and automation identities should be minimized, monitored, and scoped. Do not embed long-lived secrets in client-side code or public repositories. Upcube may terminate sessions or require re-authentication for security events. Phishing resistance matters: train users not to paste passwords into model prompts or untrusted forms that mimic login.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Workspaces should follow least privilege. Only grant admin rights to people who need them. Separate duties for billing, security settings, key management, and content administration when practical. Review invites, guest access, and abandoned projects. Remove access promptly when people leave. Permission mistakes are a common source of data exposure; treat membership changes as security events. Project-level boundaries can reduce blast radius when a single member account is compromised.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Platform and customer-managed keys must be protected. BYOK credentials should be stored in supported secret paths, rotated, and revoked when unused. See the BYOK Data Handling policy for routing and provider-side boundaries. Key leakage can cause data exposure and unexpected provider spend. Monitor unusual usage where tools allow it. Do not share keys in chat prompts. Prefer short-lived credentials or scoped keys when providers offer them.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Integrations expand the blast radius of a compromised account. Grant minimal scopes, prefer short-lived tokens where available, and disconnect unused services. State-changing integrations (write access to repos, messages, tickets, cloud resources) should require approval workflows and human review for sensitive operations. Customers must ensure connected systems are authorized for the data they receive. Periodic access reviews should include integration owners and token ages.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Approval packets, receipts, and evidence records help teams inspect risky actions. They improve process security only when humans actually review them. Do not rubber-stamp approvals. Preserve evidence when investigating incidents. Remember evidence features are product tools, not automatic legal certification. Access to evidence should be limited to roles that need it. Define dual-control for production writes and external messaging where risk warrants it.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Operational and security logging may record authentication events, admin changes, errors, route metadata, and abuse signals. Logs are used to operate, secure, and troubleshoot the service. Customers should not expect every model prompt to be absent from all logs if logging is required for reliability or security. Minimize secrets in free text. Log retention follows the Data Retention policy’s security and diagnostics categories. Anomalous usage spikes can indicate compromised keys or runaway automation and should be investigated promptly.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Local runtimes shift some execution risk to customer-managed environments. Customers must patch devices, control network exposure, and protect local model artifacts and caches. Local execution does not remove the need to secure Ethen accounts and any remote metadata channels that remain. Validate which parts of a workflow are local versus remote before processing highly sensitive data. Endpoint detection, disk encryption, and least-privilege OS accounts are customer controls that matter in local modes.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

If you believe you found a security vulnerability in Ethen, report it through published security or support channels with enough detail to reproduce the issue. Do not exploit vulnerabilities beyond what is necessary to demonstrate them, and do not access other customers’ data. Good-faith reports help improve the product. Unauthorized attacks, spam scanning that degrades service, or public dump of exploit details before coordination may violate the Acceptable Use Policy and law. We may prioritize reports based on severity and impact. Include affected URLs, timestamps, and clear reproduction steps when possible.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

If Upcube confirms a security incident affecting customer personal data or workspace content in a way that requires notice under applicable law or contract, we will notify affected customers through reasonable available channels and describe known impact and response steps as information becomes reliable. Not every anomaly is an incident. Investigation quality matters more than premature public claims. Customers should maintain current admin contact details so notices can be delivered. Customer-side incidents (lost laptops, leaked BYOK keys, malicious insiders) remain customer-owned to investigate and remediate, with Upcube support where product logs help.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Enterprise customers may require additional administrative controls, questionnaire responses, or contractual security terms. Available controls depend on product maturity and plan. This public statement does not invent enterprise features that are not generally available. See the Enterprise Security page for procurement-oriented guidance and boundaries. Verified answers should be preferred over marketing language in security reviews. Roadmap items should be labeled as roadmap, not as present-tense controls.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

No online service can guarantee perfect security. Encryption, access control, and monitoring reduce risk but cannot eliminate it. Third-party providers, user devices, and misconfiguration introduce additional residual risk. This page does not claim SOC 2, ISO 27001, HIPAA, PCI, continuous penetration testing, or uptime SLAs. If such artifacts become available and are intended for customer sharing, they will be provided through appropriate channels rather than implied here. Evaluate residual risk before processing regulated or highly sensitive data. Security is risk management, not zero-risk theater.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

Read this statement with the Privacy Policy, Data Retention policy, BYOK Data Handling policy, Acceptable Use Policy, Terms of Service, and Enterprise Security page. Security expectations for voice features appear in Voice Consent and Voice Cloning policies where relevant. Policy updates may occur as the security program and product evolve. For security questions, use published contact channels rather than informal social messages that cannot be verified.

Readers should treat this section as operational guidance for product use and evaluation. Where a control or retention behavior depends on plan, region, provider route, or admin configuration, confirm the live setting in product UI or a written enterprise agreement before relying on a specific outcome. Upcube updates public policy pages when material product posture changes, but customers remain responsible for their internal compliance programs.

For teams deploying Ethen, a practical baseline includes: unique user accounts; MFA for admins; least-privilege roles; short-lived or scoped keys; no secrets in prompts; staged integrations before production write scopes; approval gates for state-changing automation; offboarding checklists; and a known vulnerability reporting path.

Document approved model providers and data classes. Review workspace membership monthly for early deployments. Monitor provider spend for BYOK anomalies that can signal leakage or runaway jobs.

This checklist is guidance, not a certification criterion. Your industry may require additional controls, contractual terms, or alternative vendors for certain data classes.

Revisit the checklist when enabling new surfaces such as voice, browser tools, or external write integrations.