BYOK Data Handling

BYOK Data Handling Policy

This policy explains how Ethen handles customer-managed provider credentials and the data paths that result when BYOK routing is enabled. It is part of Upcube’s public policy set and should be read with the Privacy Policy and Security Statement.

1. What BYOK means

BYOK means a customer supplies credentials—such as API keys or tokens—so that selected requests are authenticated against the customer’s provider account rather than solely against a platform-managed account. BYOK is a control for account selection, billing alignment, and sometimes data-path preference. It is not a guarantee of zero logging, zero retention, or zero training on the provider side. Those outcomes depend on the provider’s product terms and settings. Customers should verify provider options that matter to their risk profile. Security and finance teams should jointly review BYOK enablement because it simultaneously affects data paths, vendor management, and spend controls. A key that is convenient for developers can still be inappropriate for regulated content if the provider path is not approved.

• BYOK uses customer provider credentials.
• It is not a universal zero-retention guarantee.
• Provider settings still matter.

2. Customer provider accounts

The provider account used under BYOK is owned or controlled by the customer. The customer is responsible for account eligibility, commercial terms, usage quotas, regional settings, and compliance obligations associated with that account. Team members who can trigger BYOK routes may generate provider usage and cost. Admins should limit who can change keys and who can run high-volume automation. If multiple providers are configured, routing rules determine which account is used for a given request. Security and finance teams should jointly review BYOK enablement because it simultaneously affects data paths, vendor management, and spend controls. A key that is convenient for developers can still be inappropriate for regulated content if the provider path is not approved.

• Customer owns/controls the provider account.
• Usage may be generated by any authorized teammate.
• Routing rules select the active path.

3. Key responsibility

Customers must protect BYOK credentials as sensitive secrets. Keys should be stored using supported secret mechanisms, rotated regularly, scoped to least privilege, and revoked when staff leave or integrations change. Do not place long-lived keys in ordinary prompts, public repositories, screenshots, or unrestricted workspace fields. If a key leaks, revoke it at the provider and replace it in Ethen configuration. Upcube is not responsible for charges or abuse arising from customer key leakage outside Upcube’s verified control failures. Security and finance teams should jointly review BYOK enablement because it simultaneously affects data paths, vendor management, and spend controls. A key that is convenient for developers can still be inappropriate for regulated content if the provider path is not approved.

• Treat keys as secrets.
• Rotate and scope credentials.
• Revoke leaked keys immediately.

4. Routing behavior

When a BYOK route is selected, prompt content, attachments, tool parameters, and related request metadata needed to fulfill the call may be transmitted to the provider endpoint configured for that route. Ethen may also process operational data such as route identifiers, latency, error codes, token estimates, and workspace linkage to provide product functionality and troubleshooting. Fallback routes, if configured, may send traffic to a different provider or platform path when the primary route fails. Understand fallback behavior before enabling it for sensitive workloads. Security and finance teams should jointly review BYOK enablement because it simultaneously affects data paths, vendor management, and spend controls. A key that is convenient for developers can still be inappropriate for regulated content if the provider path is not approved.

• BYOK routes transmit request content to the provider.
• Operational metadata may remain in Ethen.
• Fallbacks can change the data path.

5. Provider terms

Provider terms of service, privacy policies, data processing agreements, and acceptable use rules may apply to BYOK traffic. Customers should review those documents for their providers. Upcube does not restate every provider policy and does not guarantee that a provider will honor a customer’s preferred retention or training opt-out unless the provider actually offers and applies that control. Conflicts between provider terms and internal customer policy are the customer’s responsibility to resolve before enabling a route. Security and finance teams should jointly review BYOK enablement because it simultaneously affects data paths, vendor management, and spend controls. A key that is convenient for developers can still be inappropriate for regulated content if the provider path is not approved.

• Provider terms apply to BYOK traffic.
• Upcube does not rewrite provider policies.
• Customers must resolve policy conflicts before use.

6. Provider logs, retention, and billing

Providers may log requests, store temporary data, bill for tokens or compute, apply abuse monitoring, or retain records according to their systems. BYOK gives customers control over provider account selection, but provider-side terms, billing, logs, and retention may still apply. Provider invoices may appear on the customer’s provider billing channel, separate from any Upcube charges. Usage shown in Ethen may be an operational estimate rather than the provider’s final bill. Customers should use provider consoles for authoritative billing and log settings where available. Security and finance teams should jointly review BYOK enablement because it simultaneously affects data paths, vendor management, and spend controls. A key that is convenient for developers can still be inappropriate for regulated content if the provider path is not approved.

• Provider logs and bills may still exist under BYOK.
• Ethen usage UI may be approximate.
• Use provider consoles for authoritative settings.

7. Workspace usage records

Even with BYOK, Ethen may store workspace-side records such as session history, run status, model route labels, approval packets, error messages, and user attribution. These records help teams review work and administer the product. The presence of BYOK does not automatically delete workspace history. Retention of workspace records follows the Data Retention policy and product settings. If a customer requires minimal workspace retention, they should configure available retention controls and operational practices accordingly.

• Workspace history may still be stored.
• BYOK ≠ automatic history wipe.
• Use retention controls where available.

8. Redaction and evidence records

Some surfaces may support redaction, receipts, or evidence packages. These features can include route metadata, tool traces, and content snippets. Customers should avoid placing secrets in free-text fields when a secret store exists. Evidence records are for reviewability. They are not a promise that all sensitive values were redacted in every log path, especially provider-side logs outside Ethen. Security teams should evaluate end-to-end paths for regulated workloads.

• Evidence features improve inspectability.
• Redaction may not cover provider-side logs.
• Evaluate end-to-end paths for sensitive work.

9. Local lanes versus provider routes

Local or private lanes, where supported, may keep model execution on customer-controlled infrastructure. BYOK provider routes send work to remote provider APIs under customer credentials. These modes are different. Do not assume a local-lane guarantee applies to a BYOK cloud provider route, or vice versa. Product labels and route selectors should be checked for each run. Mixed workflows can combine local tools with remote models; map data paths before processing confidential content.

• Local lanes and BYOK cloud routes differ.
• Check route labels per run.
• Mixed workflows need path mapping.

10. Admin and team controls

Admins should control who can add, view, replace, or delete BYOK credentials; who can select sensitive routes; and which workspaces may use high-cost providers. Role separation reduces accidental exposure. Team onboarding should include key handling rules. Offboarding should include key rotation when departing staff had access to secrets or provider consoles. Audit which automations hold permission to spend against BYOK accounts.

• Limit who can manage keys.
• Rotate on offboarding.
• Review automation spend permissions.

11. Revocation and rotation

Customers can revoke provider keys in the provider console and update or remove them in Ethen configuration. After revocation, routes depending on that key should fail until replaced. Rotation should be planned to avoid breaking production automations. Maintain a change process for key updates. If Upcube detects suspected credential exposure in product channels it controls, it may notify customers or disable a route where appropriate, but customers remain primary owners of key hygiene.

• Revoke at provider and in Ethen.
• Plan rotations for automations.
• Customers own day-to-day key hygiene.

12. Related policies

Read this policy with the Privacy Policy, Data Retention policy, Security Statement, Terms of Service, Acceptable Use Policy, and AI Use Policy. Enterprise agreements may add customer-specific key handling requirements. Questions about BYOK configuration should go to published support or admin documentation paths. Policy updates may occur as BYOK features expand.

• Related policies complete the picture.
• Enterprise contracts may add requirements.
• Features and docs may evolve.

When BYOK applies

BYOK applies only where the product supports customer-managed credentials for a given provider or route. Availability can vary by surface, plan, and configuration. If BYOK is not enabled, platform-configured provider paths may be used instead.

• Feature-dependent: Not every model route may support BYOK.
• Admin-controlled: Keys should be managed by trusted admins.
• Provider terms still apply: Customer provider agreements remain relevant.
• Operational metadata: Ethen may still process routing and usage records.

Policy status

This BYOK policy describes current product posture for customer-managed credentials without unsupported zero-retention or certification claims.

• Conservative framing: Provider-side behavior is acknowledged.
• Customer control: Keys, scopes, and rotation are customer-owned.
• Workspace records remain: Product history may still exist.
• Related security pages: See Security and Enterprise Security.

Not legal advice

These pages explain product and policy posture for Upcube / Ethen. They are not legal advice and do not replace counsel for your jurisdiction, industry, or use case.

Evidence and claim boundaries

This statement describes Ethen’s current posture without making unsupported certification or compliance claims. Configuration, provider selection, and enterprise agreements can change data paths and controls.

• No certification claim: No SOC 2, ISO 27001, HIPAA, or PCI certification is claimed here.
• Provider-dependent behavior: Providers may apply their own terms, logs, and retention.
• Shared responsibility: Customers control keys, members, and integrations they enable.
• Human responsibility: Users remain responsible for prompts, outputs, and approvals.

Related reading

BYOK should be read with privacy, retention, security, and terms pages.

• Privacy Policy
• Data Retention
• Security Statement
• Terms of Service

Related policies

• Terms of Service

  Account and workspace use rules.

• Privacy Policy

  Data categories and user rights.

• Acceptable Use Policy

  Prohibited and restricted uses.

• AI Use Policy

  Output review and high-impact boundaries.

• Security Statement

  Security posture overview.

• BYOK Data Handling

  Customer-managed keys and routing.

• Data Retention

  Retention categories and deletion.

• Cookie Policy

  Cookies and similar technologies.

Frequently asked questions