Least privilege and zero trust come first
YEETUM LLC, operating FunkyRouter, designs the service around two rules. Least privilege means each person, service, API key, and node should receive only the permissions needed for its current task. Zero trust means we do not grant access merely because a request comes from our network, a Texas location, a customer-owned device, or company-controlled hardware. Identity, permission, resource, and current state are checked at each boundary.
These are operating principles, not a promise of perfect security. We use scoped credentials, separate human and service identities, signed webhooks, fail-closed data paths, content-free usage records, and privacy-bucketed public telemetry to reduce access and collection. The Security page identifies controls that remain under implementation or independent review.
Scope and our roles
This notice applies when you visit funkyrouter.ai, join the private-beta waitlist, create or use an account or organization, manage an API key, purchase credit, call the FunkyRouter API, enroll a provider Mac, view network data, or communicate with us about FunkyRouter.
FunkyRouter acts in different legal roles for different processing:
- Controller or business. We determine why and how we process website, waitlist, account-administration, billing, fraud, security, product, and legal-compliance data.
- Processor or service provider. For a business customer's personal data in prompts, messages, tool content, and outputs, we process on the customer's documented instructions under the Data Processing Addendum.
- Provider-node operator. Node identity, hardware, posture, health, capacity, usage, and earnings records are processed for fleet security, service delivery, audit, and payment purposes.
Third-party services you choose outside FunkyRouter have their own roles. For example, if you send a request through OpenRouter, OpenRouter processes it before it reaches us under OpenRouter's terms. It is not a FunkyRouter subprocessor merely because you chose that route.
Data we process
| Category | Examples from the current implementation | Source |
|---|---|---|
| Website and edge data | IP address, network and browser data, route, status, timing, referrer, session traffic, Turnstile token and challenge result, rate-limit key, and Cloudflare security signals. | Your browser, device, and Cloudflare |
| Waitlist and communications | Email, source, sanitized referrer, consent purpose and version, status, timestamps, and any information you send in a support or legal communication. | You, WorkOS, or the legacy waitlist form |
| Account and organization | Name, email, WorkOS user and organization IDs, organization name, membership, role, permission, session and security data, workspace settings, and default project ID. | You, your organization administrator, and WorkOS |
| API-key and audit data | Key ID, display name, type, scoped permission, status, creator, timestamps, actor/action/target fields, idempotency hashes, and revocation history. FunkyRouter's ledger does not store the one-time plaintext organization key. | You, WorkOS, and FunkyRouter services |
| Inference content | Prompts, messages, supported parameters, optional tool content, and model outputs needed to answer a request. The current beta contract is text chat completions; unsupported modalities and fields fail closed. | You, your authorized users, or a route you select |
| Usage and service metadata | Request, organization, project, key and serving-node IDs; model and artifact revision; input/output/total token counts; timestamp, latency, stream flag, terminal status, bounded finish reason, error code, credit reservation, settlement, and charge. | FunkyRouter gateway, ledger, and node |
| Billing and transaction data | Customer email, pack, amount, currency, Checkout intent and session IDs, event ID and type, payment status, credit grant, ledger entries, and fraud or dispute status. Card data is submitted to Stripe, not FunkyRouter. | You and Stripe |
| Provider and device data | Device name, P-256 public key, credential hashes, node and authorization IDs, hardware class, OS and agent version, model and runtime revision, capacity, memory and thermal state, heartbeat, latency/proximity signal, status, and earnings. | Your Mac, its operating system, and FunkyRouter |
We do not intentionally collect full payment-card numbers, account passwords, raw Secure Enclave private keys, or plaintext node tokens. Do not place those values in prompts or support messages.
Why we process it
| Purpose | Data used | Legal basis where required |
|---|---|---|
| Provide the requested service | Account, inference, usage, node, and transaction data | Contract and customer instructions |
| Authenticate and authorize | Identity, organization, permission, session, key, and device data | Contract and legitimate security interests |
| Meter, reconcile, and bill | Content-free usage, credit, Checkout, and financial records | Contract and legal/accounting obligations |
| Secure and operate the service | Edge, audit, fraud, error, fleet, posture, and health data | Legitimate interests and legal obligations |
| Manage the beta and communicate | Waitlist, account contact, consent, and message data | Consent, requested communications, and legitimate interests |
| Comply with law and enforce agreements | Relevant account, audit, transaction, and security records | Legal obligations and legal claims |
We do not sell personal data for money, share it for cross-context behavioral advertising, run targeted advertising, or use customer prompts or outputs to train or fine-tune models.
Exact service stack and data boundary
This table describes the configured shared Texas broker and published Swift MLX node release. Published source and release availability do not establish installation or live inference acceptance. Open-source software runs inside FunkyRouter's systems and does not become a data recipient merely because it is in the stack.
| Layer | Exact implementation | Data boundary | Deployment status |
|---|---|---|---|
| Website and account application | Cloudflare Worker built with Vinext 1.0.0-beta.8, Next.js 16.3.3, and React 19.2.8 Source | Identity-aware web backend. It has no D1 database or direct SQL client; control-dependent account writes fail closed when the control API is unavailable. | Website runtime inventory. Website availability does not prove the separate API or inference path. |
| Public API and control plane | Cloudflare Tunnel to FunkyRouter's Go Bifrost fork, with an OpenAI-compatible facade, service-authenticated control API, PostgreSQL, and the shared-pool broker backend Source | Authenticates organization keys, applies model and request limits, reserves credit before dispatch, and records content-free terminal usage metadata. | The broker backend is configured. Live inference acceptance depends on a ready enrolled node, the exact deployed runtime and model, and a successful authenticated request with usage settlement. |
| Authoritative records | FunkyRouter-operated PostgreSQL ledger; Bifrost SQLite is limited to gateway provider and governance configuration Source | Stores account projections, safe key metadata, waitlist, billing, audit, usage, node, and fleet records. It has no prompt or completion body columns. | PostgreSQL is the pilot authority; final backup, expiration, and cross-tenant acceptance remain launch gates. |
| Shared Texas inference broker | Go broker dispatching to operator-approved Apple Silicon nodes over outbound TLS 1.3 mutual-TLS WebSockets Source | Selects eligible nodes from the shared texas-shared pool without customer, project, organization, or API-key scheduling affinity. Admission checks node identity, approved Texas placement, revocation, runtime, artifact, and fresh capacity. | A connected or account-linked Mac is not automatically available for routing. Broker readiness and credentialed inference must be verified for the installed release. |
| Swift node beta release | FunkyRouter Swift node agent v0.0.23 using MLX Swift runtime mlx-swift-lm-3.31.4 on company-controlled Apple Silicon Source | Processes the pinned qwen/qwen3.8-27b model in process, with no public or loopback inference listener. Operator-approved enrollment authenticates the Mac; MDM is optional deployment tooling. This beta does not provide hardware attestation or hide inference content from the Mac's administrator. | The published company-beta feed identifies the available release. Release availability does not establish installation on a Mac or live serving acceptance. Developer ID signing, notarization, and cryptographically signed updates remain distribution gates. |
Managed services that receive data
- Cloudflare, Inc. — Workers, DNS, Turnstile, rate limiting, edge delivery, and the current pilot tunnel. Serve and protect the website and account application, verify anti-abuse challenges, enforce endpoint limits, and route the current pilot edge connection.
- WorkOS, Inc. — AuthKit, organizations, sessions, roles, memberships, and organization API keys. Authenticate people, maintain workspace membership and permissions, manage hosted sign-in and signup, and issue or revoke scoped organization API keys.
- Stripe, LLC — Hosted Checkout and payment-event processing. Collect payment, prevent fraud, process prepaid-credit purchases, and return signed transaction status to the FunkyRouter ledger.
The complete active register, vendor legal links, processing locations, and inference-content boundary are published at the Subprocessor and Technology Register.
Inference content and zero data retention
What ZDR means here. For the normal private-beta inference path, FunkyRouter's policy is no intentional persistent storage of prompts or completions. Content must exist transiently in gateway and inference-backend memory to validate, route, infer, and stream the response. The configured broker selects an eligible, operator-approved Mac running MLX Swift in process. The checked-in beta gateway configuration disables the Bifrost log store, content logging, raw request/response storage, object-storage retention, per-request storage overrides, and telemetry. The PostgreSQL usage ledger contains identifiers and service metadata, not prompt or completion body columns.
What ZDR does not mean. ZDR does not remove account, waitlist, usage, billing, audit, security, node, or support records. It does not apply when you intentionally include content in a support message. It also does not make process memory immune to compromise or prevent legally required preservation. The configured beta API ingress uses a Cloudflare edge/tunnel path, so Cloudflare may technically process content in transit before it reaches the Texas gateway.
A third-party aggregator terminates its own connection before sending a new request to FunkyRouter. If you use OpenRouter or another aggregator, review and configure that service separately. FunkyRouter's ZDR policy covers only the portion of the path we control.
How we disclose data
We disclose the minimum data reasonably needed:
- To Cloudflare, WorkOS, and Stripe for the narrow purposes described above and in the current subprocessor register.
- To the company-controlled inference machine performing a request. The configured broker selects an eligible Swift MLX node over its outbound mutual-TLS connection. The node receives request content, but its inference payload does not carry customer, organization, project, API-key, or provider-owner scheduling affinity.
- To your organization administrators for workspace, member, key, billing, node, and usage administration permitted by their role.
- To professional advisers, courts, regulators, or law enforcement when required by law or reasonably necessary to protect rights, safety, the service, or a legal claim, with notice where legally permitted.
- In a merger, financing, reorganization, bankruptcy, or sale, subject to appropriate confidentiality and continued legal obligations.
- At your direction or with your consent.
Public network statistics are separately aggregated and withhold usage for periods below the configured distinct-organization privacy floor. The public contract rejects tenant and node identity fields.
Retention and deletion
We minimize retention by data type. Where a fixed production schedule has not yet completed operational acceptance, we say so instead of inventing a deadline.
| Data | Current rule |
|---|---|
| Prompts and completions | Transient for the request; no intentional application database, log-store, or object-store retention in the normal beta path. End-to-end deletion verification remains a launch gate. |
| Waitlist | Until you withdraw, the beta program ends, or the record is no longer needed for admission and consent history. |
| Account and organization | While the account is active and afterward as needed for security, disputes, legal duties, and documented deletion. Organization deletion tombstones the tenant and revokes access. |
| Usage, audit, and security metadata | As needed to meter, reconcile, prevent abuse, investigate incidents, and prove service events. A tested automatic metadata-expiration schedule is not yet represented as live. |
| Billing and financial ledger | For applicable accounting, tax, fraud, chargeback, audit, and legal periods. Financial history may survive account deletion. |
| Node, authorization, and earnings | During enrollment and afterward as needed for credential revocation, fleet integrity, audit, disputes, and payment. |
| Vendor records | Under the applicable WorkOS, Stripe, and Cloudflare account, security, legal, and deletion settings and agreements. |
We may retain a limited record when law requires it or when necessary to establish, exercise, or defend legal claims. Deidentified or aggregated information may be retained if we maintain it without attempting to reidentify it.
Your privacy rights
Depending on where you live and the law that applies, you may request confirmation or access, correction, deletion, or a portable copy of certain personal data. You may also opt out of a sale, targeted advertising, or qualifying profiling and appeal a denied request. Our intended and current policy is no sale and no targeted advertising.
We authenticate requests using information already associated with the account and may ask for additional information when reasonably needed. We may deny or limit a request where permitted by law, including when we cannot verify identity or must retain a record for security, financial, legal, or third-party rights.
When the Texas Data Privacy and Security Act applies, we respond to an authenticated request without undue delay and no later than 45 days, subject to the permitted 45-day extension with notice. If we deny a request, you may appeal by replying to the decision with Privacy Appeal. If an appeal is denied, we will provide information about contacting the Texas Attorney General.
During the private beta, submit a request through the verified contact method in your beta invitation or order, or through the authenticated support channel made available to your account. A publicprivacy@funkyrouter.ai address will be published only after delivery and response handling are provisioned and tested.
Locations, transfers, and age limits
FunkyRouter is operated from Fort Worth, Texas, United States. The intended inference service processes prompt and completion content on the Texas gateway and company-controlled Texas pool, subject to the current Cloudflare pilot ingress disclosure above. Website, identity, payment, security, and support data may be processed elsewhere in the United States or other countries used by our service providers.
Where applicable law requires a transfer mechanism, we rely on the relevant vendor DPA, Data Privacy Framework participation, Standard Contractual Clauses, or another lawful mechanism. The DPA explains the mechanism for customer-controlled personal data.
FunkyRouter is a business beta and is not directed to children. You must be at least 18 years old to create an account or use the service. Contact us through the method below if you believe a child submitted personal data without authorization.
Changes and contact
We may update this notice as the beta stack, vendors, data paths, or law changes. We will update the version and date and provide additional account or contractual notice when a material change requires it. Subprocessor changes follow the separate notice process in the DPA and register.
The service is operated by YEETUM LLC in Fort Worth, Texas, United States. Private-beta customers should use the verified notice method in their invitation, order, or authenticated account. Public privacy, legal, security, support, and subprocessor mailboxes are a documented launch gate and are not represented as live until delivery is tested.