Add Acceptable Use Policy with proxy fair use rules

[ulziibay-kernel]

Summary

Adds a public Acceptable Use Policy at /acceptable-use. We currently have no documented statement of what is and isn't allowed on the platform — the closest thing is MSA §3.4, which only covers reverse engineering and resale. Two things need this closed: marketing platform-provided proxies as unlimited (unlimited with no fair-use language is an unbounded commitment), and having an express contractual basis for the enforcement actions we are already taking against abusive organizations.

The policy is built around one principle: if a person may lawfully browse a site and take an action on it, their agent may too. We don't gate use cases or ask customers to justify their targets; we prohibit conduct that would be unlawful or abusive if done by hand.

What's in it

Prohibited uses — unlawful activity, unauthorized account access, infrastructure attacks, fraud, bulk account/storefront farming on third-party services, spam, prohibited content, reselling the network as a standalone proxy/VPN, non-browsing compute consumption, taking the platform without paying, evading enforcement, plus export control and sanctions.

The AUP only prohibits; it does not grant rights. Scope carve-outs are phrased as "this does not prohibit X" rather than "X is permitted", so the policy never purports to license conduct that §2.2 and §3 govern.

Platform Abuse — a dedicated section covering the three abuse classes we have observed and enforced against, written to be specific enough to cite:

• Compute must serve browsing. Prohibits in-browser cryptocurrency mining (naming WASM/Web Worker miners and mining-pool connections), hash computation and proof-of-work, distributed computing or batch processing wrapped in a browser tab, and holding sessions open with no browsing activity to accrue runtime — including extending a session past its requested timeout by means other than genuine use. Carves out legitimately CPU-heavy web applications so this can't be read against real customers.
• One account, one allocation. Free and trial credit is a limited grant, not an entitlement. Prohibits multiple accounts or organizations to obtain more than one allocation or to exceed a plan limit, registration via address variations/aliases/relay-email techniques whose purpose is to make one party look like many, and pacing or coordinating account creation to avoid abuse detection. Carves out teams legitimately running separate orgs. Reserves the right to require a verified payment method, verified email domain, or reasonable identity/business verification before granting or continuing free credit, higher concurrency, or proxy capacity.
• Payment. Only authorized payment instruments; no one instrument across multiple orgs to multiply entitlements; no attaching a new payment method, changing plans, deleting an org, or creating a replacement org to shed an outstanding balance or restore service without settling; no chargebacks for usage actually incurred.

Proxy fair use — states plainly that unlimited means uncapped pricing, not uncapped capacity. Traffic must originate from platform browser sessions and stay in reasonable relation to session usage; no tunneling external systems, no bulk media/streaming/torrenting. Reserves rate limiting or a move to BYO proxy, with an invitation to talk to us first.

Restricted destinations — documents the destination categories our upstream network providers block (government, banking/financial, payment processors, postal, adult, bare IPs, select e-commerce), explicitly marked indicative rather than exhaustive since providers don't publish their blocklists. Framed as a network constraint rather than a judgment about the customer, with direct egress or a BYO proxy as the path forward. States explicitly that nothing in the table is a prohibited use — these are destinations our networks won't carry, not destinations customers may not visit — so the table can't be misread as a denylist.

Enforcement — enumerates the levers we actually use (rate limiting, API key revocation, terminating running sessions, restricting or revoking free credit, feature or account suspension, termination) and extends them to related accounts under common control. Notice-and-cure by default, immediate action where conduct is illegal, harms a third party, involves an unauthorized payment instrument, or threatens platform stability or economics. States that enforcement doesn't clear amounts incurred, that we may invoice for the value of resources obtained through a violation, and that spinning up a new organization clears neither the balance nor the enforcement. Also states we don't monitor session content — enforcement runs on traffic patterns, resource consumption, billing signals, and abuse reports — and gives an appeal path.

Abuse reporting — routes third-party abuse reports and domain-restriction requests to security@kernel.sh, with support@ for customer-side questions.

Other changes

tos.mdx — the AUP is a separate document incorporated by reference, which is the standard pattern for infra providers and keeps it out of enterprise redlines. Four changes make that work:

• New §1 definitions — AUP and Company-Provided Proxy Services.
• New §2.8 Company-Provided Proxy Services — proxies form part of the Services at no additional charge subject to the AUP; delivered over third-party networks whose restrictions apply and may change without notice; failure to carry a restricted destination is expressly not a breach, service failure, or service level event; right to rate limit, modify, suspend or discontinue notwithstanding §2.4's notice obligation; no-charge features are AS IS and excluded from any uptime or availability commitment. Without this, proxies aren't clearly within the defined "Services" (which is tied to the Order Form / plan page, where proxies have no priced line item) and an enterprise SLA could be read onto a free feature running over networks we don't operate.
• §3.4(d) carve-out — the clause prohibits using the Services "for the benefit of any third party," which read literally bars customers from serving their own end users, i.e. the basis on which most of the customer base operates. Adds a proviso for customer end-user service in the ordinary course. This is a pre-existing defect in the MSA, not something the AUP introduced; drafting the AUP is just what surfaced it. It amends an operative clause of a live agreement, so it warrants a specific look rather than being waved through with the rest of the package.
• New §3.6 Acceptable Use Policy — incorporation by reference, a purpose-limited modification right, suspension/termination extending to accounts under common ownership or control created to further the same violation, notice-and-cure by default with carve-outs for unlawful conduct, third-party harm, unauthorized payment instruments, and threats to platform stability or economics, and an express statement that suspension doesn't relieve accrued fees. Numbered 3.6 rather than inserted before the DPA so existing §3.5 cross-references in signed agreements stay valid.

Last Modified bumped to 9/1.

Identified but not drafted — flagged for counsel rather than fixed here: no general suspension right anywhere in §9 (only termination with 30-day cure, which is the gap organized abuse has exploited); §5.1 ties Fees to Order Form amounts so there's no basis for invoicing usage obtained through a violation; free and trial credit is entirely unaddressed, so "one account, one allocation" has no contractual counterpart; §8's fee-based cap gives a paying customer the full 12-month cap for loss via a free feature; and "Platform" is used in §3.5 and §3.6 but never defined.

• proxies/overview.mdx — Note block linking to the fair-use section and warning that restricted categories fail at the proxy layer.

Needs a decision before merge

1. Counsel review of §3.6, Platform Abuse, and Enforcement. The suspension, credit-forfeiture, related-accounts, and invoice-for-value-obtained language is the load-bearing part if we ever have to defend a ban. Drafted to be reasonable rather than maximally protective — worth a redline, particularly on whether we want the notice-and-cure default at all for free-tier abuse.

2. Do we publish the restricted-category table? Our providers deliberately don't publish theirs. Publishing gives customers real clarity and is the main reason to have this page; it also documents a capability gap competitors can quote. Recommend publishing.

3. Fair use is qualitative, not numeric. No GB ceilings, deliberately — a number we can't defend is worse than none, and it dates immediately. If we want a hard trigger, suggest an internal threshold on proxy bytes per session-hour relative to the org's cohort, reviewed rather than auto-enforced.

4. No exception process is published. Deliberately — we don't want to signal publicly that restricted destinations are negotiable. Customers are pointed at direct egress or a BYO proxy instead. Case-by-case accommodation stays a private conversation, which means Solutions and Sales need to know it isn't documented anywhere customer-facing.

5. The verification clause is a capability we don't fully have yet. "We may require a verified payment method, verified email domain, or reasonable identity or business verification" is drafted as a reserved right, which is safe to publish ahead of the tooling — but confirm we're comfortable stating it before the enforcement paths exist.

6. Consider an abuse@ alias. Reports currently route to security@, which is monitored and already published. Site operators and network providers look for abuse@ by convention, so an alias forwarding to the same place is cheap insurance.

7. Retroactivity. This gives us clean prospective grounds. It does not by itself paper over enforcement against organizations that signed up under the current MSA — check with counsel whether existing §3.4 plus the payment terms are enough for anything we act on before 9/1.

8. The .gov row goes stale if government routing ships. If a proxy path that carries government domains lands, the restricted-destinations table is wrong on day one. It needs qualifying per proxy type rather than deleting — the restriction would apply to some networks and not others. Worth confirming the sequencing against the 9/1 date.

Testing

Prose only — no build step in this repo. Internal link paths follow the existing convention (no /docs prefix); the /acceptable-use page is unlisted in docs.json, matching how tos, privacy, dpa, and security are handled. Not previewed in Mintlify. Diff checked for internal context, customer identifiers, and vendor names — none present.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Kernel	🟢 Ready	View Preview	Aug 27, 2026, 4:13 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[cursor]

Stale comment

Risk assessment: Low (re-evaluated after update)

Re-checked the full diff against main after the post-approval commits (e8ad5c2, 260d6ec, 15e3bc0). Risk remains Low. The existing approval is left in place; this review does not re-approve.

What the diff actually changes

• Adds acceptable-use.mdx (static Mintlify policy page).
• Adds ToS §3.6 in tos.mdx incorporating that page by reference, plus a Last Modified date bump.
• Adds a short Note in proxies/overview.mdx linking to the fair-use section.

No application code, CI, infrastructure, docs.json, or CODEOWNERS changes. No CODEOWNERS file exists in this repo.

Why Low (not Very Low)

This is documentation-only, but it is a new public policy page plus contractual ToS language (suspension, related-account enforcement, fee survival). That is larger than a typo or copy tweak.

Why not Medium or higher

Blast radius is docs-site rendering. No production logic, auth/billing implementation, schema, or shared services are modified.

Delta since the prior approval (2b82363)

The later commits only edit acceptable-use.mdx: they remove the anti-detection, exceptions, and changes sections, and point abuse reports at security@kernel.sh instead of support@. That narrows published policy text and does not add codepaths or infra. Risk did not increase, so approval is not revoked.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Stale comment

Risk assessment: Low (re-evaluated after update)

Re-checked the full diff against main after commit 695c6f1. Risk remains Low. The existing approval is left in place; this review does not re-approve.

What the diff actually changes

• Adds acceptable-use.mdx (static Mintlify policy page).
• Adds ToS §3.6 in tos.mdx incorporating that page by reference, plus a Last Modified date bump.
• Adds a short Note in proxies/overview.mdx linking to the fair-use section.

No application code, CI, infrastructure, docs.json, or CODEOWNERS changes. No CODEOWNERS file exists in this repo.

Why Low (not Very Low)

This is documentation-only, but it is a new public policy page plus contractual ToS language (suspension, related-account enforcement, fee survival). That is larger than a typo or copy tweak.

Why not Medium or higher

Blast radius is docs-site rendering. No production logic, auth/billing implementation, schema, or shared services are modified.

Delta since the last assessment (15e3bc0)

The new commit only adds two sentences in acceptable-use.mdx clarifying that restricted proxy destinations are network constraints, not prohibited uses. No new files, codepaths, or infra. Risk did not increase, so approval is not revoked.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Stale comment

Risk assessment: Low (re-evaluated after update)

Re-checked the full diff against main after commit e88c5e3. Risk remains Low. The existing approval is left in place; this review does not re-approve.

What the diff actually changes

• Adds acceptable-use.mdx (static Mintlify policy page).
• Updates tos.mdx with AUP / Company-Provided Proxy Services definitions, new §2.8, a §3.4(d) carve-out for customer end-user products, and §3.6 incorporating the AUP by reference (plus a Last Modified date bump).
• Adds a short Note in proxies/overview.mdx linking to the fair-use section.

No application code, CI, infrastructure, docs.json, or CODEOWNERS changes. No CODEOWNERS file exists in this repo.

Why Low (not Very Low)

This is documentation-only, but it is a new public policy page plus contractual ToS language (suspension, related-account enforcement, fee survival, SLA exclusion for unmetered proxies). That is larger than a typo or copy tweak.

Why not Medium or higher

Blast radius is docs-site rendering. No production logic, auth/billing implementation, schema, or shared services are modified.

Delta since the last assessment (695c6f1)

The new commit only edits tos.mdx: it defines AUP and Company-Provided Proxy Services, adds §2.8 (no-charge provision, third-party destination restrictions, rate-limit/withdraw rights, AS-IS / SLA exclusion), and carves customer end-user service out of §3.4(d). That is additional legal prose on the same docs surface. No new files, codepaths, or infra. Risk did not increase, so approval is not revoked.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Risk assessment: Low (re-evaluated after update)

Re-checked the full diff against main after commit 92f6779. Risk remains Low. The existing approval is left in place; this review does not re-approve.

What the diff actually changes

• Adds acceptable-use.mdx (static Mintlify policy page).
• Updates tos.mdx with AUP / Company-Provided Proxy Services definitions, new §2.8, a §3.4(d) carve-out for customer end-user products, and §3.6 incorporating the AUP by reference (plus a Last Modified date bump).
• Adds a short Note in proxies/overview.mdx linking to the fair-use section.

No application code, CI, infrastructure, docs.json, or CODEOWNERS changes. No CODEOWNERS file exists in this repo.

Why Low (not Very Low)

This is documentation-only, but it is a new public policy page plus contractual ToS language (suspension, related-account enforcement, fee survival, SLA exclusion for unmetered proxies). That is larger than a typo or copy tweak.

Why not Medium or higher

Blast radius is docs-site rendering. No production logic, auth/billing implementation, schema, or shared services are modified.

Delta since the last assessment (e88c5e3)

The new commit only edits acceptable-use.mdx: it rephrases carve-outs from “is permitted” to “this does not prohibit,” drops the express product-building grant from the resale bullet, and stops saying restricted destinations are permitted to visit. That is wording tightening on the same docs surface. No new files, codepaths, or infra. Risk did not increase, so approval is not revoked.

  

_{Sent by Cursor Automation: Assign PR reviewers}