KyGit is run402's git vault under its own product
domain, operated by Kychee, Inc. Your use of KyGit is governed by the run402 Privacy Policy,
reproduced below with the vault lane described precisely; the canonical copy lives at
run402.com/humans/privacy.html.
The strongest privacy statement on this page is structural, not contractual: your repository
history is encrypted on your own machine, under a key we never receive. Most of what a
privacy policy usually promises about your code, we could not do to it if we tried.
Overview
Run402 provides cloud infrastructure — databases, APIs, authentication, storage, static site hosting, and the KyGit git vault. Unlike a static website, Run402 necessarily stores and processes data to deliver its services. This policy explains what data we collect, how we use it, and how we protect it — and, for the vault, what we structurally cannot see at all.
Data We Collect
Run402 collects and stores the following data as part of normal service operation:
the envelope, never the letter
Git vault data — your repository history reaches us as ciphertext only, encrypted on your machine under keys we never receive; we cannot decrypt it. What we do retain is enumerated plaintext metadata: that a vault exists and whose it is, ciphertext sizes and object ids, generations and push cadence, access times, policy state, and the structural skeleton of maintenance. We do not see branch names, commit messages, file paths, commit ids, or any un-keyed digest of plaintext. The full observer-by-observer boundary is on the how-it-works page and in the threat model.
API keys — anon keys and service keys generated for each project (stored hashed)
Database contents — all data you store in your project's PostgreSQL schema, including tables, rows, and application data. (This is the non-vault lane; vault content is the ciphertext-only entry above.)
File uploads — files stored through the storage API (S3-backed). If you deploy a website from your project, the published files pass through the content store in plaintext, because serving a website requires reading it — deploying is an explicit act, and a vault-only project deploys nothing.
Server logs — API request logs including IP addresses, timestamps, endpoints called, and response codes (retained for 30 days)
Run402 account and authority records — human and agent principals, sign-in authenticators, organization memberships, project grants, and generic audit events needed to explain who acted and under which Run402 authority
Public Buzz/Nostr identity links — the selected Nostr public key/npub, exact signed public proof event, proof protocol, linked Run402 principal, verification time, current revocation state, and (for human proofs) a statement that Run402 verified the direct session and fresh passkey. Completing this flow intentionally makes the Run402-principal/Buzz-identity correlation public and durable. Revocation preserves the historical public proof.
Buzz human-adoption receipts — the terminal consent receipt and references to its separately stored public identity link and ordinary organization membership. The signed approval and target session are used to verify completion; browser fragments and credentials are not stored as adoption diagnostics.
Optional Buzz setup diagnostics — coarse allowlisted preflight event/check/error names, operating-system family, major runtime/client versions, released Buzz capability-fixture id, and install-context class. The diagnostic payload contains a random event id used only for 24-hour deduplication. Aggregate counters are retained for 180 days; no raw diagnostic event, account/principal, wallet, Buzz identity, persistent installation id, relay/domain/path, command, or free text is stored in the diagnostic tables. Ordinary API transport logs remain covered by the server-log policy above.
Authentication data — email addresses and hashed passwords for users of your applications (stored in your project's schema)
How We Use Data
We use the data we collect exclusively for:
Service delivery — provisioning and operating your databases, APIs, storage, vaults, and hosted sites
Terms enforcement — detecting and responding to violations of our Acceptable Use Policy
Billing — processing payments and tracking usage against lease limits
Product reliability — measuring aggregate, non-identifying Buzz setup failure points so compatibility and remediation can be improved
Attribution and accountability — publishing user-approved identity links and retaining lifecycle/audit evidence so public identity, Run402 authority, and historical consent can be inspected independently
Run402 does not sell your data. We do not use your data for advertising. We do not train AI models on your data — and for vault content, this is not a policy choice we could later reverse: we hold ciphertext and no key, so there is nothing on our side to train on, index, sell, or hand to whoever asks next.
Buzz setup diagnostics are best-effort and never affect setup. Set RUN402_TELEMETRY=0 in the agent environment to disable their delivery.
Data Storage and Security
Vault ciphertext rests in a dedicated Amazon S3 vault bucket whose policy, enforced by AWS rather than by our application code, requires create-only writes and refuses bulk deletion. Your repository ciphertext moves directly between your machine and storage — our servers never handle it. The optional mirror replicates your ciphertext to a bucket you own.
Databases are hosted on AWS Aurora Serverless v2 (PostgreSQL 16) with encryption at rest (AES-256) and in transit (TLS 1.2+)
File storage uses Amazon S3 with server-side encryption
Static sites are served via Amazon CloudFront + S3
Project isolation — each project receives its own PostgreSQL schema with row-level security. Projects cannot access each other's data.
Backups — automated database backups with 7-day retention
Data Retention
Your data lifecycle follows a ~104-day soft-delete grace. Your live site and end-user traffic keep working throughout — only the project owner's control-plane access (deploys, secret rotation, subdomain claims) is gated after day 14. Read-side vault routes are never lifecycle-gated: a vault stays readable while its organization is in billing grace, and the opt-in mirror means your history is never hostage to a billing state in the first place.
Active — full read/write access to all data
Past due (days 0–14) — everything works normally; billing contact gets the first warning email
Frozen (days 14–44) — site keeps serving end users; control-plane writes return 402; subdomain is reserved so no one else can claim it; second warning email
Dormant (days 44–104) — site still serves; scheduled (cron) functions pause; final warning email 24 hours before deletion
Purged (day ~104+) — all project data, functions, deployments, and secrets are permanently deleted; subdomain becomes claimable by others 14 days later
Any tier renewal, topup, or upgrade during grace instantly reactivates the project and clears the countdown. Server logs are retained for 30 days and then automatically deleted.
Hosted Application Data
Data stored by the applications you build on Run402 — including end-user data collected by your apps — is your responsibility. You are the data controller for any personal data your applications collect. Run402 acts as a data processor on your behalf. You are responsible for ensuring your applications comply with applicable privacy laws (GDPR, CCPA, etc.).
Third-Party Services
Run402 uses the following third-party services:
Amazon Web Services (AWS) — infrastructure hosting (Aurora, S3, CloudFront, Lambda). AWS Privacy Policy. For vault content, AWS holds only your ciphertext — the same unreadable bytes we do.
x402 / Coinbase — payment facilitation for USDC transactions on Base. Coinbase Privacy Policy
Run402's own pages — kygit.com included — set no cookies and use no third-party analytics. To measure which ad campaigns deliver real users, if you arrive from an ad the page stores the click's attribution parameters (such as gclid and UTM tags) in your browser's local storage and sends them only to our own API.
When you copy the agent prompt on run402.com, we may issue a unique promo code and attach it to the prompt. The code is unique so that your agent receives its starter credits, and it lets us connect that visit to what the agent later does on Run402. Once the code reaches your agent it identifies a machine account, not a person: no browser, cookie, device, or personal identifier crosses over with it. Copying still works if the code cannot be issued.
Children's Privacy
Run402 is not directed at children under 13. We do not knowingly collect personal information from children. If you are a developer building an application directed at children, you are responsible for ensuring COPPA compliance in your application.
Your Rights
You may export your data at any time using the Run402 API while your lease is active — for a vault, run402 repos mirror and run402 repos recover give you a complete, independently recoverable copy of your history with no server involved. If you need to exercise data subject rights (access, correction, deletion) for data stored in your project's database, you can do so directly through the API. For requests related to Run402 organization-level data, contact legal@kychee.com. Note the structural limit in your favor: for vault content we can delete ciphertext and metadata, but we cannot produce a readable copy of your repository history for anyone — including you — because we never hold the key.
Changes to This Policy
We may update this privacy policy from time to time. The “last updated” date at the top of this page reflects when changes were last made. Continued use of Run402 after changes constitutes acceptance of the updated policy.