Privacy statement

1. Scope and status

This statement covers the website at guntech.cloud and the API gateway operated at the same domain. GunTech Cloud is an invitation-only private beta operated by a single founder. It is an independent product. It is not affiliated with, endorsed by, sponsored by or operated by Anthropic, and it is not an official Anthropic service. Anthropic's own terms and privacy policy govern the underlying model service.

Three items in this statement are deliberately left unfinished, because the operator has not supplied them and this project's release gates require them:

• the identity of the operating legal entity and its registered address (section 2);
• a contact route that has been tested in both directions (section 3);
• retention and deletion periods (section 8).

No certification, audit result, regulatory approval, service level or availability figure is claimed anywhere on this page, because none exists. The private beta terms set out the service conditions that accompany this statement, and the documentation describes the technical contract.

2. Who is responsible for the data

3. How to contact the operator

4. Data the service holds

There are two separate sets of data, and they should not be confused with each other. The first is supplied by a person who asks for pilot access. The second is produced by applications that call the gateway. A third, smaller set exists for the operator's own console account.

4.1 Pilot requests (the early-access list)

The pilot form stores one row per submission. These are the fields, and they are the complete set:

The form also contains one field that no human is expected to fill in. If it is filled, the submission is rejected and nothing is stored. In production the form additionally requires a Cloudflare Turnstile check; if Turnstile is not configured, the operator's code disables the form and the intake endpoint returns a 503 rather than silently accepting submissions that no bot protection covers.

The list does not ask for, and the database cannot store, a phone number, a company name, a password, an identity document or a billing detail. There is no other field.

4.2 Gateway operational metadata

When an application calls the gateway with a valid project key and the request passes validation, one row is written to the usage ledger for that request. The columns are:

The prompt body and the model's response body are not stored in that ledger. They are not columns in the table, and the function that writes a row has no parameter through which a prompt could be passed. A request rejected for a missing, malformed or revoked key is answered with 401 and produces no row at all.

Around that ledger, the database also keeps monthly totals per project and UTC month (settled tokens and in-flight reservations), short-lived reservation rows with an amount and an expiry, and per-key request counters per minute. None of these hold request content.

4.3 Console account, credentials and keys

• The operator's account record holds an email address and a password hash computed with PBKDF2-SHA256 at 210,000 iterations with a per-account random salt. The plaintext password is never stored.
• A console session record holds a SHA-256 digest of the session token, the account it belongs to, and its creation and expiry times. The cookie value itself is never written to the database.
• A project key record holds an internal identifier, the project it belongs to, a short identifying prefix such as gt_live_a1b2c3, a SHA-256 digest of the full key, and the creation, last-use and revocation timestamps. The key cannot be reconstructed from the database, and it is displayed exactly once, at creation.
• The operator's upstream Anthropic credential is stored as an environment secret for the running process. It is not in any table, it is never returned to a client, and it appears only in the outbound request header to Anthropic.

4.4 What is deliberately never stored

No prompt text. No model response text. No plaintext project key. No plaintext session token. No plaintext password. No upstream provider credential. No response cache, because this version has no caching. No client IP address in the database.

Two limits on that statement, because a promise is only worth the scope it names. The prompt necessarily exists in the gateway process's memory while a request is being handled, and it is necessarily sent to Anthropic for the model to answer it; the claim here is only that it is not written to the usage ledger. And logs written by the infrastructure this service runs on are outside the code's control, which section 6 sets out.

5. Cookies, browser storage and third-party code

The public pages of this site set no cookies and write nothing to browser storage. The pilot form, when it is armed, loads Cloudflare Turnstile from challenges.cloudflare.com; Turnstile processes signals about the browser to distinguish automated submissions, and Cloudflare's own terms and privacy policy govern that processing. It is the only third-party script the site is permitted to load: the content security policy the site is served with allows scripts from this domain and, when the form is armed, from that one Cloudflare origin.

The administrator console, which is not public and is provisioned by hand, sets one cookie named gt_session. It is HttpOnly, SameSite=Strict, marked Secure when served over HTTPS, and expires after seven days. The database stores only a digest of its value. There is no self-service signup, so no account cookie is ever set for a visitor.

No third-party analytics, advertising or tracking service is loaded by this site, and no script here contacts a third-party endpoint. If first-party measurement events are added later, this section will be updated to describe them.

6. What the server writes to its own log

The gateway writes one JSON line per event to its process log. For a gateway request, that line contains a request identifier, the HTTP status, the outcome label, the latency in milliseconds, and, on a completed call, the input and output token counts. For console actions it contains an event name and internal identifiers such as a project or key identifier. Never written: prompt text, response text, the project key, the upstream credential, the session token, or the client IP address.

Two caveats, stated plainly:

• A rejected request is still logged as a status and an outcome, and a static-file error records the requested path. Nothing in these lines carries request content, but they are not empty.
• Infrastructure and platform logs are outside this code. The host or network provider that runs this service may keep its own request logs, which can include the requested path, the client address and the response status, under that provider's terms. Separately, the operator's login rate limiter derives a truncated SHA-256 digest of the client address and keeps it in the process's memory for a 15-minute window; because that digest is unsalted and the address space is small, it should be treated as pseudonymous rather than anonymous. Reviewing infrastructure logging and exception traces for prompt or credential material is a required release gate in this project and is not yet complete.

7. The Claude data flow and cross-border transfer

When a pilot application sends a request to POST /v1/messages with a valid project key, the gateway authenticates the key, validates the request, applies the project's rate and token rules, and then forwards the validated request to Anthropic's Messages API so that the model can answer. Anthropic processes that request as an independent service provider under Anthropic's own terms and privacy policy, not under this statement. GunTech Cloud does not control that processing and cannot describe it on Anthropic's behalf; Anthropic's current documentation is the reference for it.

This is a cross-border transfer. The operator is in Indonesia, and both the upstream model service and the infrastructure this service runs on are outside Indonesia. The processor and vendor review, the data classification and the transfer assessment that this project's release gates require before production customer data is handled have not been completed. Until they are:

• do not send personal data about other people, sensitive or regulated data, or confidential third-party material through this gateway;
• treat anything sent through the gateway as disclosable to the upstream model provider and to the infrastructure provider;
• wait for the operator to publish the outcome of that review before using the gateway for data of that kind.

On hosting: the operator's stated deployment target is Cloudflare, using Workers for the service and D1 for the database, and this repository's schema is written for that engine; the same source also runs as a single server process against a SQLite database. Whichever is used, the infrastructure provider processes data under its own terms, and its platform logs are the caveat described in section 6.

Two things this statement cannot cover: data an application sends to Anthropic directly, outside this gateway, and anything Anthropic or Cloudflare retains under their own policies.

8. Retention

No retention period is in force. Retention and deletion defaults are an open requirement in this project and require legal review before they are set; this document will publish the actual periods rather than a placeholder number, and will state the date they take effect.

What happens mechanically today:

• Expired console sessions are deleted by a maintenance sweep that runs every 15 minutes, and an expired session is also removed when it is encountered.
• Rate-limit counters older than one hour are deleted by the same sweep.
• A quota reservation that never settles expires after five minutes and is released, so an interrupted request does not consume a project's monthly allowance indefinitely.
• Usage events, monthly totals and pilot requests are not deleted automatically at the time of writing. They remain until the operator sets a retention policy or acts on a request under section 9.

9. Access, export and deletion requests

The beta is operated by one person, so these requests are handled by hand. There is no self-service export, no deletion endpoint and no account portal.

9.1 A pilot request

A message sent to the contact route in section 3 can ask for a copy of the stored entry, or for its deletion. The operator can produce the fields listed in section 4.1 and can delete the row; deletion is recorded by setting a deletion timestamp, after which the entry stops appearing in the operator's list. Both actions are manual operations on the operator's database.

9.2 Gateway metadata

The usage ledger holds request-level counters for a project, but it contains no prompt text and no identifier for the person who wrote a prompt, so a specific prompt cannot be produced or erased from it: that content was never recorded. What the operator can do is delete the usage events belonging to a project, or delete the project, which removes its events as well. If a request concerns an application's end users, the operator will need the project identifier to act at all, and can then remove only the counters, not the content.

9.3 Console account

The operator's own account record and its sessions can be deleted on request. This is the operator's account, not a customer account, because the beta has no self-service accounts.

9.4 What the operator commits to

During the private beta, the operator will make a reasonable effort to acknowledge a data request and to act on it. No response time is guaranteed. The service is founder-operated without a support desk, and a self-imposed target would not be a contractual commitment, so none is offered here. A request may be declined where the operator cannot verify that the requester is the person the data belongs to, or where the operator is required to retain something; if a request is declined, the reason will be given.

One gap, stated plainly: the contact route in section 3 is not yet verified, so a message sent today may not arrive. Until that channel is verified, this draft cannot promise that a data request will be received. Fixing it is a release-gate item, and this section will be updated when it is done.

10. Indonesian personal-data and electronic-system rules

The operator is based in Indonesia, and Indonesian personal-data protection and electronic-system and electronic-transaction rules may apply to this service where relevant. Whether they apply to a given processing activity, and what they would require here, including any registration, notification, transfer or consent obligation, has not been determined. No professional legal review has been completed. This statement does not assert compliance with those rules, with the EU General Data Protection Regulation, or with any other regime, and no certification or approval is claimed. A review is pending; its outcome, and any change it requires to this statement, will be published on this page. Until then, this document describes what the system does, not a claim that doing it is sufficient.

11. Changes to this statement

This is draft version 0.1, dated 8 October 2026, and it is not in force. A change will be published on this page with a new version number and date. Material changes affecting an active pilot will also be raised through the channel the operator uses to reach that pilot. Because there is no self-service account, a pilot that cannot accept a change can ask the operator to withdraw its access, and the keys issued to it will be revoked.

12. Related documents

• Private beta terms of use — access conditions, acceptable use, and the limits of the token ceiling.
• API documentation — the exact request contract, supported parameters and error behaviour.
• guntech.cloud — what the product is, and what it is not.