OrbitMesh Privacy Policy

Effective date: 2026-03-11
Last updated: 2026-03-11

This Privacy Policy explains how OrbitMesh collects, uses, stores, discloses, and protects personal data and other information when we provide OrbitMesh products and services.

This policy is written for OrbitMesh's current technical implementation as of the date above.

If this policy conflicts with a signed agreement (for example, an MSA, DPA, or enterprise order form), the signed agreement controls for that customer relationship.

1. Scope

This Privacy Policy applies to:

• OrbitMesh application services and APIs.
• OrbitMesh-hosted dashboard and related public pages.
• Operational and support processing related to service delivery.

This Privacy Policy does not apply to:

• Customer-managed systems outside OrbitMesh.
• Third-party websites or services not operated by OrbitMesh.

2. Roles (Controller and Processor)

OrbitMesh can act as both:

• A controller (or equivalent role) for account, business contact, billing, and service administration data.
• A processor (or service provider) for customer telemetry/evidence data processed on behalf of customers.

For personal data contained in customer traffic telemetry, the customer is generally the controller, and OrbitMesh processes data under customer instructions and contractual terms.

3. Data We Collect

3.1 Account, tenant, and organization data

We collect and store:

• User identifiers (including Kinde subject/user id).
• Name (if provided).
• Email address.
• Tenant, organization, membership, role, and environment context.
• User session records (selected tenant and expiry).

3.2 Authentication and security data

We process:

• Kinde JWT claims (issuer, audience claims where configured, org claims, role claims).
• Kinde user profile data when needed to complete identity fields (for example, missing email in token).
• Relay JWT claims (tenant_id, cluster_id, gateway_id, jti, exp and entitlement claims where applicable).
• Relay token metadata (token hash, last 4 characters, issue/expiry, status, refresh metadata).
  Note: plaintext relay tokens are not stored in token tables.

3.3 Gateway and control-plane data

We collect and store:

• Gateway, cluster, and agent IDs.
• Gateway health/status and keepalive timestamps.
• Config identifiers (for example, SHA-256 values), config times, and gateway version fields.
• Upload session metadata (status, S3 key path, expected/actual size, checksums/ETag when provided, expiry, errors).

3.4 Forensic evidence and telemetry data

OrbitMesh ingests gateway telemetry and evidence bundles. The current implementation is designed to avoid collecting full request/response bodies, but it does collect a broad set of metadata and security telemetry, including:

• Request metadata (IDs/hashes, path/URI/host/query hashes and sampled/truncated fields).
• Client/network metadata (IP bytes, user-agent hash and sampled prefix).
• Authentication and authorization telemetry.
• TLS/security telemetry (cipher/protocol identifiers, JA3 hash, cert-related metadata, SNI-related signals, verification flags).
• Upstream/request outcome telemetry (status, body sizes, upstream service/hash, rate-limit outcomes).
• Chain-of-custody fields (prev_entry_hash, entry_hash).

Truncation/sampling controls include:

• user-agent sample max length: 32
• request URI sampled suffix max length: 96
• selected SSL identity sample max length: 32
• certificate serial length max: 20

3.5 Aggregated metrics and analytics data

We store aggregated metrics for route, auth, TLS, client, upstream, and config evidence analysis.
Metrics tables include structured columns and raw_payload JSONB snapshots for full-fidelity recordkeeping.

3.6 Query and audit data

When users run analytics/query endpoints, we process and store:

• Query text.
• Scope parameters (tenant/cluster/gateway and time range).
• Runtime metadata (duration, rows returned, bytes scanned, status, error message).

3.7 Compliance bundle and artifact data

For compliance workflows, we process and store:

• Compliance job metadata (requested_by, filters, status/progress, time windows).
• Bundle metadata and artifact references.
• Generated artifacts such as manifests, provenance outputs, HTML reports, and PDF reports.
• Artifact integrity fields (hashes, sizes, URIs).

3.8 Billing and entitlement data

Where billing is enabled, we process and store:

• Customer email/name and provider customer identifiers.
• Subscription and checkout metadata.
• Plan and entitlement metadata.
• Webhook payload JSON, event status, and processing errors.

3.9 Public page and waitlist data

On public pages, we currently integrate:

• GoatCounter analytics script.
• FormSubmit waitlist form fields (email, gateway, siem, optional company, optional note).
• Paddle checkout bridge script on billing checkout page (when enabled).

4. Data We Do Not Intentionally Collect

OrbitMesh is designed to avoid full request/response body capture in gateway evidence collection.
However, customers control upstream traffic content and gateway configurations, so personal data can still appear in metadata, queryable fields, or customer-submitted content.

5. Sources of Data

We receive data from:

• Customers and users directly (account setup, billing, support, waitlist).
• Customer gateway/relay components sending telemetry/evidence.
• Identity provider responses (Kinde).
• Billing provider events (Paddle) when billing is enabled.
• Browser/client interactions with the dashboard/public pages.

6. How We Use Data

We use data to:

• Authenticate users and enforce access control.
• Provide tenant-aware dashboards and APIs.
• Ingest, verify, index, and analyze telemetry/evidence.
• Generate compliance artifacts and integrity outputs.
• Operate billing, subscriptions, and entitlement enforcement.
• Maintain service security, availability, debugging, and abuse prevention.
• Provide customer support and incident response.
• Improve product functionality and reliability.

7. Legal Bases (where applicable)

Depending on jurisdiction, we rely on one or more of:

• Contract performance.
• Legitimate interests (security, abuse prevention, service operations, product improvement).
• Legal obligation compliance.
• Consent (for specific optional interactions where required).

8. Cookies, Local Storage, and Similar Technologies

Current implementation includes:

• orbitmesh_tenant cookie:
  • purpose: tenant context routing for authenticated dashboard sessions
  • attributes: httpOnly, sameSite=lax, secure in production
  • max age: 7 days
• sidebar_state cookie:
  • purpose: UI preference
  • max age: 7 days
  • not httpOnly
• localStorage:
  • orbit-theme (theme preference)
  • request explorer tour flag (seen)
• sessionStorage:
  • orbitmesh.me cached auth/me payload with 5-minute TTL

Public pages may load third-party scripts (see Section 10).

8.1 Cookie categories and purposes

Depending on the page and service function, OrbitMesh and its partners may use:

• Strictly necessary technologies to operate authentication/session and core site functionality.
• Preference technologies to store user interface settings (for example, theme and sidebar state).
• Analytics technologies on public pages to understand usage trends and improve site content.

8.2 Your choices about cookies and similar technologies

You can generally control these technologies through:

• Browser settings (block/delete cookies).
• Device/platform privacy controls.
• In-page controls where available.

Blocking some technologies may reduce or break certain service functionality (for example, authentication state or saved preferences).

8.3 Global Privacy Control and Do Not Track

Do Not Track (DNT) is not a consistently implemented standard across browsers and services. OrbitMesh does not currently represent universal DNT signal handling across all endpoints.

For Global Privacy Control (GPC) and similar opt-out preference signals, OrbitMesh processes privacy requests through direct request channels (Section 15.1) and applies legally required handling based on applicable law and deployment context.

9. Data Sharing and Disclosure

We disclose data only as needed to provide services, comply with law, protect rights/security, or under customer direction/contract.

Categories of recipients may include:

• Identity provider and authentication infrastructure.
• Object storage/cloud infrastructure providers.
• Billing/payment providers.
• Public-page analytics/form providers (for those public pages).
• Professional advisors and legal/regulatory authorities where required.

We do not sell personal information for money.
We do not use customer telemetry for third-party advertising profiling.

10. Third-Party Services and Policy Links

The following services are currently integrated or deployment-supported in OrbitMesh implementations:

Important note on Chrome usage: OrbitMesh uses a local Chromium-compatible binary in server runtime to render PDF artifacts. OrbitMesh does not intentionally submit report content to Google services as part of this conversion flow. Browser vendor policies still apply to the runtime software.

11. International Data Transfers

OrbitMesh deployments may process data in regions selected by OrbitMesh and/or customer infrastructure configuration (for example, configured object storage region).

Where applicable, cross-border transfers are handled using legally recognized transfer mechanisms under applicable law and contractual commitments.

11.1 Storage locations and media (deployment defaults)

In default package deployments, data may be stored in:

• Postgres data volume (for metadata/control-plane tables): /opt/orbitmesh/postgres/data
• Relay runtime/evidence paths (archives, exports, WAL, state): /opt/orbitmesh/relay
• Nginx shared runtime/cert paths: /opt/orbitmesh/nginx
• Apiserver cache/temp paths: /opt/orbitmesh/apiserver/cache and /opt/orbitmesh/apiserver/duckdb-temp
• Object storage configured for evidence/artifacts (for example S3 or S3-compatible endpoints)

Customers operating self-hosted deployments control host path provisioning, infrastructure hardening, and region/storage endpoint selection.

12. Retention

Retention is based on data class, operational need, and legal obligations.
Current implementation-specific behavior:

Where law requires longer retention (for example, legal hold, fraud prevention, tax/accounting obligations), data may be retained beyond normal operational windows.

13. Security and Safeguards

Current safeguards include:

• TLS controls:
  • relay to apiserver gRPC transport uses TLS credentials with minimum TLS 1.2
  • nginx TLS configuration allows TLS 1.2 and TLS 1.3
• Object storage controls:
  • presigned uploads use private ACL
  • optional SSE-KMS for uploads/artifacts when KMS key is configured
• Access and tenancy controls:
  • tenant-aware auth middleware for dashboard APIs
  • tenant/session checks for protected endpoints
• Query safety controls:
  • read-only SQL restrictions (single statement, SELECT/WITH subset, forbidden keyword checks)
• Token protection:
  • relay token table stores hash and last4, not plaintext token
• Local-only relay debug REST:
  • loopback bind and loopback source checks

Operational caveats and shared-responsibility notes:

• Some controls are configuration-dependent (for example, KMS encryption is optional).
• Some local/debug paths rely on loopback restrictions and deployment hardening.
• Relay local REST auth middleware is currently placeholder allow-all and relies on loopback-only access controls.
• Kinde audience-claim enforcement depends on configured validator behavior and may not be enforced when audience is unset.
• In debug configurations, logs may include raw telemetry/config JSON; operators should restrict access and log retention accordingly.
• compliance_enable_debug defaults to true in current config loading behavior; operators should set explicit production logging policy.

14. Customer Controls and Choices

Customers can:

• Choose storage providers/endpoints and regions via deployment config.
• Configure retention and cleanup policies at deployment/contract level.
• Restrict data collection scope through gateway/relay configuration.
• Disable or avoid optional public-page flows (for example, waitlist or analytics script usage) in controlled deployments.

15. Data Subject Rights

Depending on applicable law and role allocation (controller vs processor), rights may include:

• Access
• Correction
• Deletion
• Restriction
• Portability
• Objection
• Withdrawal of consent (where processing is consent-based)

For customer telemetry where OrbitMesh acts as processor, requests should generally be directed first to the relevant customer controller.

15.1 How to exercise privacy rights

To submit a privacy rights request, contact:

• privacy@orbitmesh.io

Please include enough information for us to:

• identify your relationship to OrbitMesh,
• locate relevant records,
• and evaluate/apply your request under applicable law.

Where legally required, OrbitMesh will respond within statutory timeframes.

15.2 Identity verification and authorized agents

Before fulfilling certain requests, OrbitMesh may verify identity and request scope to protect against unauthorized disclosure or deletion.

Where legally permitted, authorized agents may submit requests on behalf of an individual, subject to proof of authority and verification procedures.

15.3 Appeals and complaints

If you believe a rights request was denied in error, you may request reconsideration by replying to the decision notice or contacting privacy@orbitmesh.io.

Where applicable law provides additional escalation rights (for example, complaint to a data protection authority), those rights remain available.

16. Account Deletion and Data Deletion Workflows

Current account deletion flow includes:

• Deleting the user in Kinde through management API.
• Deleting local user account and related records.
• Tenant cleanup for certain owner-only tenant paths.

Data deletion may not always be immediate in every subsystem due to:

• backup/replication lag,
• legal retention requirements,
• and staged cleanup behavior across evolving modules.

17. Children

OrbitMesh services are designed for business use and are not intended for children.
We do not knowingly provide OrbitMesh services directly to children.

18. Automated Decision-Making

OrbitMesh performs automated analytics/scoring and rule-based security/compliance processing for operational purposes. OrbitMesh does not use these features for consumer credit eligibility or similarly regulated profiling decisions.

19. Changes to This Privacy Policy

We may update this Privacy Policy to reflect product, legal, or operational changes.
When material changes are made, we will update the "Last updated" date and provide notice as required by law or contract.

20. Contact Information

For privacy, security, or data protection requests, contact:

• Privacy contact: privacy@orbitmesh.io (replace if different)
• Security contact: security@orbitmesh.io (replace if different)

If you are an enterprise customer, you may also use your contractual support/security contact paths.

21. Region-Specific Disclosures

Depending on applicable law, additional notices may apply (for example, EEA/UK GDPR and U.S. state privacy laws).
OrbitMesh will provide region- and contract-specific addenda where required.

For U.S. state privacy frameworks, OrbitMesh does not sell personal data for money and does not use customer telemetry for cross-context behavioral advertising.

21.1 Additional U.S. state privacy disclosures

For relevant U.S. state privacy laws, OrbitMesh generally processes personal information in the categories described in Section 3, for the purposes in Section 6, from the sources in Section 5, and discloses categories of information as described in Sections 9 and 10.

Categories of personal information disclosed for business purposes may include:

• identifiers and business contact information,
• account and tenant context data,
• commercial/billing metadata (where billing is enabled),
• internet/network activity and usage telemetry,
• security and authentication metadata,
• support and communication records.

OrbitMesh does not sell personal information for monetary consideration.

21.2 Sensitive personal information

OrbitMesh does not intentionally collect sensitive personal information for inferring characteristics about consumers in a consumer-advertising context.

To the extent sensitive data is processed (for example, security telemetry fields or customer-supplied content), processing is limited to:

• providing and securing services,
• preventing abuse/fraud/security incidents,
• legal/compliance obligations,
• and other permitted business purposes under applicable law.

21.3 Do Not Sell or Share

OrbitMesh does not sell personal information for money and does not share customer telemetry for cross-context behavioral advertising.

For public-page analytics and similar technologies, OrbitMesh will honor legally required opt-out rights through available controls and request channels.

21.4 Consumer rights by state

Depending on your state of residence and legal applicability, rights may include:

• right to know/access,
• right to deletion,
• right to correction,
• right to data portability,
• right to opt out of certain profiling/targeted advertising/sharing,
• right to non-discrimination for exercising rights.

You may exercise these rights through the contact channels in Section 15.1.

22. Government and law enforcement requests

OrbitMesh may disclose information when required by applicable law, legal process, or enforceable governmental request.

When permitted, OrbitMesh applies process controls such as:

• legal review of request scope and validity,
• minimization of disclosed data,
• and, where lawful, notice to affected customer/controller.

23. Data Privacy Framework statement

OrbitMesh is not currently publicly representing certification under the EU-U.S. Data Privacy Framework, UK Extension, or Swiss-U.S. Data Privacy Framework unless explicitly stated in a signed contract or an updated public notice.

If this status changes, OrbitMesh will update this Privacy Policy and related trust documentation.

---

Appendix A: Component-to-Processing Map

• orbit-agent:
  • collects request-level shallow forensics, security telemetry, and aggregated metrics.
• orbit-relay:
  • buffers, compresses, retries, and exports evidence bundles; stores local WAL/archive/export state.
• orbit-apiserver:
  • authenticates users/relays, issues upload targets, finalizes sessions, converts evidence to parquet, stores metadata/analytics, runs query/compliance/billing APIs.
• orbit-dashboard:
  • manages authenticated UX, tenant cookie/context, API proxying, and selected public-page integrations.
• orbit-package:
  • defines deployment paths, volumes, TLS ingress defaults, and runtime operational defaults.

Appendix B: Third-Party URL List

• Kinde Privacy Policy: https://docs.kinde.com/trust-center/privacy-and-compliance/privacy-policy/
• Chrome Browser Privacy Policy: https://www.google.com/chrome/privacy/
• Google Privacy Policy: https://policies.google.com/privacy
• AWS Privacy Notice: https://aws.amazon.com/privacy/
• Paddle Privacy Policy: https://www.paddle.com/legal/privacy
• GoatCounter Privacy: https://www.goatcounter.com/help/privacy
• FormSubmit Privacy: https://formsubmit.co/privacy.pdf
• Let's Encrypt Privacy Policy: https://letsencrypt.org/privacy/