Security as shared responsibility.

Security Statement

Security Statement

1. 1. Security posture

   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. Exact control implementations can vary by component and maturity. Any certification, audit, or test materials, if available, are provided separately through applicable published or enterprise materials. 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.

   Security controls and retention behavior can depend on plan, region, provider route, and admin configuration. Confirm the applicable product settings and any written enterprise agreement for your environment. Customers remain responsible for their internal security and compliance programs.

2. 2. Shared responsibility

   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.

3. 3. Account access

   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.

4. 4. Workspace permissions

   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.

5. 5. Provider keys and BYOK

   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.

6. 6. Connected services

   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.

7. 7. Approvals and evidence

   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.

8. 8. Logging and monitoring

   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.

9. 9. Local and private lanes

   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.

10. 10. Vulnerability reporting

    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.

11. 11. Incident communication

    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.

12. 12. Enterprise controls

    Enterprise customers may require additional administrative controls, questionnaire responses, or contractual security terms. Available controls depend on product maturity and plan. See the Enterprise Security page for procurement-oriented guidance and boundaries. Security reviews should distinguish controls available in the evaluated environment from controls that are unavailable or customer-managed.

13. 13. Limitations

    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. No SOC 2, ISO 27001, HIPAA, PCI, continuous penetration-testing status, or uptime SLA is represented by this statement. Any applicable assurance materials, if available, are provided separately through appropriate channels. Evaluate residual risk before processing regulated or highly sensitive data.

14. 14. Related policies

    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.

15. 15. Practical hardening checklist

    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.

Related security reading

• Enterprise SecurityProcurement-oriented overview.
• BYOK Data HandlingKey and provider path responsibilities.
• Privacy PolicyData categories and access context.
• Data RetentionLogs and security record retention.

FAQ