Home / Legal

Privacy Policy

Draft — not yet effective; requires legal review before publication. Last updated: [EFFECTIVE DATE]

This privacy policy explains what [LEGAL ENTITY NAME] ("agent-next", "we", "us") collects when you use our website, waitlist, and hosted sandbox service, and what we do with it. "Service", "Sandbox", "Customer Content", and "Operational Records" have the meanings given in our terms of service.

The short version: we collect what an infrastructure service needs to run — your waitlist and account details, API Key records, usage and metering data, service logs, and abuse signals. We do not sell personal data. We do not run advertising trackers. We do not use your sandbox content to train models. Code and files inside a Sandbox are deleted with the Sandbox; records about your use are kept for the periods in Section 8.

1. Who we are

We are [LEGAL ENTITY NAME], [REGISTERED ADDRESS]. For privacy questions, contact [PRIVACY EMAIL]. For other contacts, see the terms of service.

2. What we collect

Waitlist records. When you join the waitlist: your email address, name, organization, the use case you describe, and the IP address and time of your submission. Each entry also carries its review status — pending, approved, or rejected — and the time it was last updated. We use them to run the waitlist and invitations.

Free-grant records. When we approve an invitation, we record the Free Grant it issued: a normalized form of your email address — computed so that address variants that reach the same mailbox (for example, +tag suffixes, or dots in a Gmail address) count as one person — stored solely to enforce the one-grant-per-person limit, together with your email address, the API Key issued, and the date of the grant.

Account information. When your account is created: your email address, name, and organization. We use it to create and administer your account and communicate with you.

API Key records. When we issue an API Key we store a cryptographic hash and a short display prefix of the key — the full key is shown once, when created, and cannot be recovered from our systems. For each key we also keep credential-management records: the key's identifier and name, when it was issued, when (if ever) it was revoked, and its configured limits — the concurrent running and paused Sandbox quotas and the hour credit on the account.

Usage and metering data. For each Sandbox: its identifier, the template it was built from, its pause/resume settings, any metadata you attach at creation, when it was created, its most recent activity, and its lifecycle events — create, pause, resume, kill — with timestamps, including whether a pause was started by you or automatically (for example, idleness, an exhausted hour budget, or a revoked key). From these we compute how long each Sandbox ran and was paused and the hours your account has used. We also collect timestamped CPU-usage samples linked to the Sandbox and the node it ran on.

Abuse and enforcement data. Records of abuse-detection findings and enforcement actions on your account and Sandboxes — automated ones (sustained-CPU findings, the Sandbox pauses they trigger, account suspension after repeated findings, and per-account sandbox-creation rate limits) and manual ones (an operator suspending, reinstating, or exempting your account) — each with its timestamp, the action taken, the reason, and the measurements behind it (for example, CPU-seconds over a detection window); your account's abuse-suspension state and its abuse-detection exemption flag; and abuse reports we receive about your account.

Service logs. Like most online services, we keep technical logs: IP addresses and request metadata ([VERIFIED LOG FIELDS]), error and capacity events, and lifecycle actions such as automatic pauses. We retain these for [DATA RETENTION PERIOD FOR LOGS].

Payment data. We collect none during the Beta. If we launch paid plans, payments will be handled by [PAYMENT PROCESSOR -- TBD AT PAID LAUNCH], and we will update this policy before then.

Sandbox contents. The code, files, and data you put inside Sandboxes are Customer Content, not account data. Section 5 explains how we handle them.

Transient rate-limit state. The gateway also keeps small amounts of rate-limiting state in memory only: a per-IP counter of waitlist signup attempts and per-account sandbox-creation rate state. This state is never written to our database, is not backed up, and is cleared when the Service restarts.

We collect this information directly from you and from your use of the Service.

3. Why we collect it (legal bases)

Where the GDPR or a similar law applies, we rely on these legal bases:

• To provide the Service (performance of a contract). Account information, API Key records, and usage data are needed to operate your account, authenticate API calls, meter usage against your hours and limits, and run the Service you asked for.
• To run the waitlist and invitations (legitimate interests). Waitlist answers help us admit a workable mix of beta users and size capacity honestly; we keep them only for that purpose.
• To protect the Service and other people (legitimate interests). Service logs, abuse and enforcement data, and capacity metering let us detect and stop abuse, secure the platform, prevent farming of free hours, plan capacity, keep the Service available for everyone, and keep the records we need to enforce our terms and to defend or bring legal claims.
• To communicate with you (contract and legitimate interests). Beta invitations, service announcements, security notices, and notices about changes to our terms. Any non-essential email we ever send includes an opt-out.
• With your consent (consent). For anything that needs consent, we say so at the point of collection, and you can withdraw it at any time.
• To comply with the law (legal obligation). Responding to lawful requests and keeping records the law requires us to keep.

About automated controls. Some controls act on your account automatically: running Sandboxes are paused when your hour budget is exhausted or your API Key is revoked, and automated abuse detection can restrict or suspend accounts. We do not use your personal data for advertising profiling. Whether any of these automated controls is a decision producing legal or similarly significant effects within the meaning of laws such as GDPR Article 22 is for counsel to assess: [AUTOMATED DECISIONS ASSESSMENT]. If an automated restriction affects you and you believe it is wrong, you can contact [ABUSE EMAIL] to ask for review.

4. What we do not do

• We do not sell your personal data.
• We do not share your personal data for cross-context behavioral advertising.
• We do not use Customer Content — your code, files, and data inside Sandboxes — to train machine-learning models.
• We do not run advertising cookies, cross-site trackers, or ad-based analytics on our site.

5. Sandbox contents (Customer Content)

Code and files you place in a Sandbox are deleted when the Sandbox is killed or times out, unless you deliberately use a persistence feature. We do not back them up — keep your own copies. We do not routinely access Sandbox contents. We may access them where we reasonably need to respond to an abuse report, to comply with law or a legal request, or to protect the security and integrity of the Service.

What deleting a Sandbox does not remove. Records about the Sandbox — its identifier, template, create-time metadata, pause/resume settings, lifecycle events, metering, CPU samples, and abuse findings and enforcement actions about it — are not contents. They are Operational Records, retained as described in Section 8. Do not put secrets or sensitive personal data in create-time metadata.

Who is responsible for what. We act as controller for the data described in this policy — waitlist, account, API Key, usage, abuse, and log data. When Customer Content you place inside a Sandbox contains personal data, we process that content as a processor acting on your instructions; you may be a controller for that content, or a processor acting for your own controller — whichever role you have, the duties that come with it are yours. Whether and how we make a data processing agreement covering Customer Content available is not yet decided: [DPA AVAILABILITY AND ACCEPTANCE -- OWNER DECISION].

6. Sharing

We share personal data only as described in this policy:

Sub-processors and infrastructure providers. These companies process data on our behalf to run the Service:

Sub-processor changes. Before we add or replace a sub-processor that processes account data or Customer Content, we will give you notice and a way to object on reasonable data-protection grounds: [SUBPROCESSOR CHANGE NOTICE AND OBJECTION PROCEDURE].

Legal requests and abuse cooperation. We may disclose personal data to respond to lawful requests, legal process, and abuse reports from our hosting providers; to enforce our terms and acceptable use policy; and to establish or defend legal claims. We validate requests and disclose only what they require; in some cases the law restricts us from telling you about a request: [LEGAL REQUEST VALIDATION AND NOTICE EXCEPTIONS].

Business transfer. If we are involved in a merger, acquisition, or sale of assets, we may transfer personal data as part of that transaction, with notice to you where required.

Other than the sub-processors above, we do not provide your personal data to third parties for their own purposes, and we do not sell it.

7. Where your data lives

The Service runs on compute infrastructure in the United States (DigitalOcean). Cloudflare provides our DNS, edge network, and object storage: [CLOUDFLARE PROCESSING LOCATIONS]. If you use the Service from outside the United States, your data is transferred to and processed in the United States. Where applicable law requires a legal mechanism for such transfers, we will rely on [TRANSFER MECHANISM AND SAFEGUARDS]; contact [PRIVACY EMAIL] for a copy once one is adopted.

8. How long we keep it

• Waitlist records — while the beta waitlist and invitations are running, and no longer than [WAITLIST RECORD RETENTION PERIOD].
• Free-grant records — while the beta Free Grant program runs, so the one-grant-per-person limit can be enforced, and no longer than [GRANT RECORD RETENTION PERIOD].
• Account information — while your account exists. After closure we delete or anonymize it, except for records we must keep for legal, abuse-enforcement, or dispute purposes.
• API Key records — while your account exists; issuance and revocation records are kept afterwards for security, abuse-enforcement, and dispute record-keeping for [CREDENTIAL RECORD RETENTION PERIOD].
• Usage and metering data, and Operational Records about deleted Sandboxes (creation metadata, lifecycle events, pause/resume settings) — while your account is active, and afterwards only for as long as needed for accounting, abuse prevention, and disputes, and no longer than [OPERATIONAL RECORD RETENTION PERIOD].
• CPU samples — [CPU SAMPLE RETENTION PERIOD].
• Abuse and enforcement data — for enforcing our terms and preventing repeat abuse: [ABUSE RECORD RETENTION PERIOD].
• Service logs — [DATA RETENTION PERIOD FOR LOGS].
• Backup copies — we regularly back up the Service's database — the waitlist, account, API Key, usage, metering, abuse, and enforcement records above, never Sandbox contents — into compressed archives on our infrastructure. On our infrastructure, the most recent [BACKUP RETENTION PERIOD] archives are kept and older ones are deleted automatically. Depending on how the Service is operated, archive copies may also be stored off-site under [REMOTE BACKUP LOCATION POLICY], which states where those copies live and when they are deleted; local rotation does not delete off-site copies. When we process an applicable deletion request, subject to the exceptions above, we delete the records from the live database, and from backup archives only as those archives age out of retention: we do not rewrite individual archives, so a deleted record can remain in an existing archive until that archive expires, and a backup restored later brings its records back until they are deleted again.
• Transient rate-limit state — in memory only; never written to our database and cleared when the Service restarts.
• Sandbox contents — deleted with the Sandbox, as described in Section 5.

If you ask us to delete your data, we delete it, except where the law requires us to keep specific records, or where the law permits us to keep them for the purposes this Section states — in particular the security, accounting, abuse-enforcement, and legal-claim retention described above: [DELETION EXCEPTIONS AND RETENTION BASIS].

9. Security

No internet service can promise perfect security, but we work to deserve your trust:

• API Keys are stored only as cryptographic hashes; the full key is displayed once and cannot be recovered from our systems.
• Internal telemetry and metrics endpoints are not reachable from public traffic: they are served on a separate internal listener. The endpoints that ingest CPU telemetry and serve capacity counters additionally require a per-node token; the read-only metrics-scrape endpoint relies on that internal listener alone for its access control.
• The Service's control-plane API — the API that lists, creates, pauses, resumes, and deletes Sandboxes and reports usage — is scoped to each account's own API Keys: one account cannot use the control-plane API to list or manage another account's Sandboxes.
• A Sandbox's own network endpoints are not protected by your API Key. Each Sandbox has per-port endpoints on the Service's domain. The Service does not authenticate whoever calls them: while a Sandbox is alive and its account's key has not been revoked, anyone who obtains an endpoint's URL can reach the service you run inside that Sandbox through it — except while enforcement cuts the endpoint off (the account is suspended, or the Sandbox has been paused by abuse enforcement), or while you have paused the Sandbox with auto-resume disabled. Treat those URLs as secrets: do not expose secrets or personal data through services you run in a Sandbox unless you put your own authentication in front of them.
• We rate-limit how often an account can create Sandboxes, block outbound email (SMTP), and monitor for sustained resource abuse such as cryptomining.
• We collect what the Service needs and no more: we do not ask for, and do not want, more personal data than this policy lists.
• [VERIFIED STAFF ACCESS CONTROLS]

10. Your rights

Depending on where you live — the GDPR, the CCPA/CPRA, and similar laws — you may have the right to:

• access the personal data we hold about you, and get a copy;
• correct or complete data that is wrong;
• delete your data, subject to the retention exceptions described in Section 8;
• port your data (receive it in a structured, machine-readable copy);
• object to or restrict processing that relies on legitimate interests;
• withdraw consent where we rely on it; and
• not be discriminated against for exercising these rights.

We do not sell or share personal information for cross-context behavioral advertising as those terms are used in the CCPA, so there is nothing for you to opt out of on that front.

To exercise a right, contact [PRIVACY EMAIL] — including through an authorized agent where the applicable law permits it. We verify requests in a proportionate way, for example from the email address on your account, and respond within the deadlines the applicable law sets — for example, within one month under the GDPR and within 45 days under the CCPA, with any extensions those laws allow, which we will explain. If you are not satisfied with our answer, you may complain to your local data protection authority.

11. Children

The Service is not directed to children. You must be at least [MINIMUM AGE] years old to use it, and we do not knowingly collect personal data from children. If you believe a child has provided us data, contact [PRIVACY EMAIL] and we will delete it.

12. Cookies and tracking

Our website uses only essential cookies and similar mechanisms — such as keeping you signed in and protecting forms against abuse. We do not use advertising, cross-site tracking, or ad-targeting cookies. Your browser can block or delete cookies; the essential ones may be required for parts of the site to work.

13. Changes to this policy

We will post changes on this page and update the date at the top, and we will notify you of material changes as described in the terms of service.

14. Contact

[LEGAL ENTITY NAME] [REGISTERED ADDRESS] Privacy questions: [PRIVACY EMAIL]