AI Use Policy

AI Use Policy details

This AI Use Policy is focused on responsible reliance. Ethen can help users move faster and keep work visible, but model outputs may be inaccurate, incomplete, unsafe, outdated, or unsuitable. Sensitive domains require human review and appropriate expertise.

1. What Ethen is for

Ethen helps users generate, organize, route, review, and preserve model work. It can support drafting, coding, summarization, transformation, research organization, model routing, local/private lanes where supported, workflow design, approval packets, evidence records, and connected-service work. Ethen is designed to make model work easier to inspect, not to remove human responsibility. A user should treat Ethen as an assistant workspace and review layer. The user decides what to submit, which model route to use, what context to include, whether a connected service should be used, whether a workflow should move forward, and whether an output should be relied on. Product labels, route information, evidence records, receipts, and approval prompts are meant to help users make better decisions. They do not guarantee that the work is correct, lawful, safe, complete, or appropriate.

• Ethen assists with model work and review.
• Users decide what to submit, route, approve, and rely on.
• Visibility features support review but do not guarantee correctness.

2. Output accuracy and limitations

Model outputs may be inaccurate, incomplete, outdated, biased, unsafe, offensive, insecure, or unsuited to the user’s purpose. A model may fabricate citations, misunderstand context, make math errors, produce insecure code, omit important caveats, misread uploaded files, overstate confidence, or generate content that infringes rights if used carelessly. Different models may produce different answers to the same prompt. Users must review outputs before relying on them. Review should include checking facts, source material, assumptions, instructions, data boundaries, model route, citations, calculations, code behavior, legal or policy requirements, and potential impact on people. For sensitive work, review should be performed by someone qualified for the domain. Ethen does not warrant that a generated output is accurate, safe, current, original, compliant, or fit for a particular purpose.

• Outputs may be wrong or unsuitable.
• Different models may disagree.
• Human review is required before reliance.

3. Professional advice and sensitive domains

Ethen does not provide legal, medical, financial, tax, insurance, employment, housing, education, safety, security-certification, or other regulated professional advice. Users may use Ethen to organize notes, draft questions, summarize material, prepare checklists, compare options, or support a professional workflow, but qualified humans remain responsible for advice, decisions, filings, treatment, engineering release, security remediation, or other sensitive outcomes. Users must not use Ethen as the sole basis for decisions that affect a person’s rights, health, money, access, safety, legal status, employment, housing, insurance, education, benefits, or essential services. When Ethen is used in a sensitive domain, users should document assumptions, review source material, test outputs, check for bias, preserve appropriate records, and obtain professional review where needed.

• Ethen does not replace professional advice.
• High-impact decisions need qualified human review.
• Sensitive workflows should document assumptions and review evidence.

4. Model providers and configuration

Depending on configuration, Ethen may route requests through third-party model providers, hosted models, open models, BYOK provider accounts, local runtimes, or other supported lanes. Providers may process requests, prompts, outputs, files, metadata, or derived context according to their own terms and settings. Provider behavior may change over time and may vary by model, account, region, enterprise setting, or API route. Users should understand their selected model route before submitting sensitive information. BYOK may route data through a customer-controlled provider account, but it does not automatically make the provider route private, local, zero-retention, zero-training, or exempt from provider policy. Local/private lanes depend on runtime setup and should be validated before sensitive use. If a user or organization has strict obligations, it should configure and test routes rather than relying on assumptions.

• Provider processing depends on route and settings.
• BYOK does not automatically mean private or zero retention.
• Local lanes require runtime validation.

5. Code generation and software changes

Generated code can contain bugs, insecure patterns, licensing issues, broken imports, missing tests, performance regressions, accessibility problems, unsafe shell commands, or incorrect assumptions about a repository. Ethen may help read code, propose plans, draft patches, explain diffs, and organize validation steps, but users remain responsible for testing and approving software changes. Before merging, deploying, or running generated code, users should inspect the diff, understand the affected files, run appropriate tests, check dependencies, review security implications, validate migrations, and confirm that the change matches product intent. Code that touches authentication, payments, secrets, data deletion, permissions, encryption, infrastructure, model routing, workflow execution, or user data requires extra care. Generated shell commands, scripts, and database operations should be treated as proposed actions, not automatically trusted instructions.

• Generated code must be reviewed and tested.
• Sensitive areas require extra care.
• Commands and scripts are proposals, not automatic truth.

6. Security findings and dual-use work

Ethen may help with defensive security work such as code review, threat modeling, vulnerability explanation, secure coding, remediation planning, detection logic, incident notes, and audit preparation. Security outputs can still be incomplete, false positive, false negative, outdated, or unsafe if applied incorrectly. A generated finding should be verified against source code, runtime behavior, logs, configuration, exploitability, and business context. Users must not use Ethen to create malware, steal credentials, exploit unauthorized targets, evade detection, exfiltrate data, maintain persistence, or automate attacks. Defensive security work should be authorized, scoped, and documented. Generated remediation should be tested before deployment. Ethen does not certify that a system is secure, compliant, free of vulnerabilities, or properly remediated.

• Security findings require verification.
• Authorized defensive work is allowed.
• Ethen does not certify security.

7. Creative, media, and rights review

Ethen may help draft copy, generate ideas, transform text, prepare creative briefs, organize campaigns, or create media-related outputs where supported. Users are responsible for ensuring that generated creative work respects intellectual property, privacy, publicity rights, confidentiality, brand rules, platform rules, and attribution requirements. A generated output may resemble existing material or may include unsupported claims if not reviewed. Users should not use Ethen to impersonate people, fabricate endorsements, create deceptive media, misuse likeness or voice, or publish content that falsely implies consent, sponsorship, authorship, or factual support. Creative teams should review generated work before publication, especially when it includes claims about products, customers, performance, pricing, health, finance, law, safety, or third parties.

• Generated creative work requires rights and claims review.
• Do not fabricate consent, sponsorship, or identity.
• Publication requires human review.

8. Voice features

If voice features are enabled, users must handle voice inputs, transcripts, generated audio, and voice settings with care. Voice data can identify a person and can reveal sensitive content. Users must not record, clone, synthesize, transform, or imitate a person’s voice without appropriate rights and consent. Users must not use voice features to deceive, defraud, harass, impersonate, bypass authentication, or create fake evidence. Voice outputs and transcripts should be reviewed before use. Transcription can be wrong, and generated audio can be misleading if the audience is not given appropriate context. Depending on configuration, voice processing may involve third-party transcription, speech, storage, or model providers. Users should understand the selected route and consent requirements before using voice features.

• Voice use requires rights and consent.
• Do not use voice features for deception or impersonation.
• Transcripts and audio outputs require review.

9. Automated and state-changing actions

Automated or state-changing actions should be treated as higher risk than draft generation. This includes actions that send messages, publish content, change files, modify code, call external APIs, schedule events, update records, change permissions, move data, trigger jobs, delete content, create accounts, or affect third-party systems. Users should review what action will happen, what data will be used, who or what will be affected, and how to reverse or stop the action. Ethen may provide approval prompts, simulations, dry runs, evidence records, and receipts where supported. Those controls help review, but they do not make an unsafe action safe. Users should keep approval gates for sensitive actions, test workflows before production use, and monitor outcomes after execution. A user who approves or triggers an action remains responsible for the result.

• State-changing actions need review.
• Approvals and simulations support but do not replace judgment.
• Users remain responsible for actions they approve.

10. Human oversight and escalation

Human oversight should match the risk of the task. Low-risk drafting may need light review. Code, security, legal, medical, financial, employment, housing, insurance, educational, personal-data, voice, or automation tasks require deeper review. Users should escalate work when they are not qualified to evaluate the output or when the output could materially affect people, money, rights, safety, or critical systems. Good oversight includes checking source material, testing outputs, reviewing data boundaries, confirming permissions, validating assumptions, comparing against trusted references, and preserving records when needed. Teams should define who may approve sensitive workflows and when a second reviewer is required. Ethen can make review more visible, but accountability stays with the user or organization.

• Oversight should match risk.
• Escalate when a task is outside your expertise.
• Teams should define approval authority.

11. User responsibility for prompts and context

The quality and safety of model work depends heavily on what users submit. Users should provide accurate context, avoid unnecessary sensitive data, respect confidentiality, identify constraints, and choose the appropriate model route. Users should not intentionally trick the model, hide harmful intent, submit data they are not allowed to use, or use Ethen to bypass policies that would apply if the work were done manually. Users are also responsible for reviewing context pulled from connected services or files. Retrieved material can be outdated, incomplete, confidential, or irrelevant. A model may over-rely on bad context. Before relying on an output, users should consider whether the underlying prompt, file, connected service, or retrieval result was correct and authorized.

• Prompt quality affects output quality.
• Do not submit unauthorized data.
• Review retrieved context before relying on outputs.

12. Reporting concerns and policy updates

Users should report unsafe outputs, confusing behavior, suspected abuse, security concerns, privacy concerns, or policy questions through the appropriate contact or support path. Reports help improve the product and clarify policy boundaries. Users should avoid publicly sharing sensitive exploit details, private data, or harmful instructions when reporting an issue. Upcube may update this AI Use Policy as models, providers, local runtimes, workflow capabilities, voice features, misuse patterns, laws, and product surfaces change. Continued use of Ethen may be subject to the updated policy where allowed by applicable terms. Users and administrators should periodically review policy changes and update their internal workflows, approval rules, and route configuration accordingly.

• Report unsafe or confusing behavior.
• Do not expose sensitive details in public reports.
• The policy may change with product and risk changes.

How this policy should be read

This policy should guide everyday use of Ethen across model routing, drafting, coding, research, workflow, connected services, BYOK, local/private lanes, and voice features where supported.

• Applies to Ethen services: This policy covers the Ethen model workspace, public website, console surfaces, model routing, workflow surfaces, and related product areas where they are available.
• Read with related policies: This page should be read together with the Terms of Service, Privacy Policy, Acceptable Use Policy, AI Use Policy, security materials, and final order or account terms.
• Configuration matters: Some behavior depends on account settings, workspace configuration, selected providers, connected services, BYOK setup, local runtime setup, and feature availability.
• No unsupported guarantees: This policy avoids claims about certifications, retention periods, provider guarantees, uptime promises, or legal rights that have not been verified for the published service.

Policy status

This page is written as public policy copy for transparency. It should be aligned with the final published agreement, product configuration, and any account-specific terms that apply to a customer or user.

• Public transparency: The page explains how Ethen expects users to handle model work, workspace data, providers, approvals, and generated material.
• Account terms still matter: A customer order, workspace setting, provider account, or connected-service agreement may add more specific rules.
• No professional substitute: The policy does not replace legal, medical, financial, security, engineering, or other professional review where that review is appropriate.

Not legal advice

This page is provided for transparency about Ethen’s intended policy posture. It is not legal advice, does not create professional advice, and should be reviewed with the final published agreement and appropriate advisers where needed.

Proof boundary

The AI Use Policy avoids unsupported claims about model accuracy, output ownership, provider behavior, local privacy, safety guarantees, and professional suitability.

• No certification claim: This policy does not claim SOC 2, ISO, HIPAA, PCI, GDPR compliance, or other certification status.
• No provider guarantee: Third-party model providers, connected services, and local runtimes have their own behavior and terms.
• No retention promise: Retention is described by category unless a final published retention period is available.
• No zero-use assumption: The page avoids unsupported zero-training, zero-retention, and never-shared claims.

What to review next

Legal and policy pages work as a system. Use the links below to understand the responsibilities, privacy posture, safety boundaries, and review expectations that apply to Ethen use.

• Terms of Service
• Privacy Policy
• Acceptable Use Policy
• AI Use Policy

Frequently asked questions