Privacy notice

This notice says what Bucker stores, where it comes from, how long it is kept, who else can reach it, and how to get it back or have it removed. It is written from the repository rather than from a template: every statement names the mechanism that makes it true, and where the mechanism is narrower than the sentence a lawyer would write, the narrower sentence is here. Where something is not yet decided — the operating entity, a contact address — it says so rather than leaving a blank that reads as an oversight.

Bucker is pre-launch. No payment provider is connected, nothing has ever charged a card, and the service is operated in one region.

Who is responsible for your data

The operating entity, its registered address and a contact address for privacy questions are not yet stated. They will be added when this draft is reviewed, and the same commit will put the address in /.well-known/security.txt, which today points at the trust page for want of one.

What Bucker is

Bucker is error monitoring for applications whose fixes are increasingly written by AI agents. You install an SDK; it sends error events from your application to Bucker; Bucker groups them into issues, projects a bounded "error essence" for a coding agent to read, can run a proposed fix in a sandbox, and records the human decision to accept or reject it. Every one of those steps produces data, and the sections below take them in turn.

What is stored, and where it comes from

Account data

• Your email address, display name and organization and project memberships.
• Your password, as an argon2id hash, never as the password itself.
• If you enable two-factor authentication, the TOTP secret, encrypted at rest with AES-256-GCM under a server-held key (domain/src/modules/auth/mfa.ts).
• If your organization uses single sign-on or SCIM, the identity your directory asserts for you, including group membership. Agents provisioned through SCIM are recorded the same way.

Telemetry your application sends

Error events and the envelopes that carry them: exception type and message, stack frames, the release and environment, request metadata, and whatever user identifiers your SDK configuration attaches. Envelopes larger than the inline limit (64 KiB by default, INGEST_INLINE_MAX_BYTES) are held in object storage and referenced by key. Events are grouped into issues, and an issue carries a denormalized copy of its title, exception and culprit.

Also on this path: structured logs, traces and spans over OTLP; cron and uptime monitor check-ins; and user feedback, which is rendered as data everywhere it appears.

Session replay

Replay records the interaction layer, not the screen: route templates with ids collapsed, click selectors, input values as the literal <masked> unless masking is turned off, network calls as method and URL template, scroll position and viewport size. It does not capture DOM mutations, screenshots or page text. Nothing leaves the page until an error is captured, and an error-free session is never transmitted.

Two things a reader should know, because the flag on the segment does not say them:

• console.error and console.warn arguments are captured verbatim (up to 200 characters) at every masking setting. Applications routinely log names and emails there, so a segment marked as masked can still carry user text in a console message.
• Credential-shaped fields — password inputs, card fields, one-time codes, anything named like a token — are masked at every setting and cannot be unmasked by configuration.

The full audit, including the two findings above, is session replay and privacy.

AI application telemetry

If you instrument your own AI application, prompt and response text is kept only according to the capture mode you set, and even the most permissive mode is scrubbed before storage (domain/src/modules/agent-observability/content-policy.ts).

The audit trail

Every action in the product — by a person or by an agent — is written to an audit log by one function (domain/src/modules/authz/audit.ts), recording what was done, by whom, on whose behalf and under what authority. Each row carries the client IP address as the reverse proxy reports it (TRUST_PROXY), which is also the key for the sign-in rate limits.

What reaches a model provider

Root-cause analysis and fix authoring send issue content to a large-language-model provider. The content is scrubbed twice first — see the next section — and there is no zero-data-retention agreement with any provider; we have not negotiated one and will not imply one. Every plan can supply its own Anthropic or OpenAI key instead of using ours, in which case the provider relationship is yours.

Scrubbing before storage, and again before a model

A scrubber runs on every ingest path — the worker pipeline, the agentless landing lane and OTLP — before anything is persisted, and no configuration flag disables it. At this "stored" tier it removes credentials: bearer tokens, vendor API keys, private-key blocks, card numbers (Luhn-checked) and high-entropy secrets. It deliberately keeps email addresses, IP addresses and user identifiers, because an on-call engineer legitimately needs them.

A second, stricter "agent" tier runs before an issue reaches a model — in the essence projection, in root-cause evidence assembly and in fix authoring — and additionally removes emails and public IP addresses. The fix-authoring path was missing that second pass until the trust page was written; the trust page keeps that history rather than presenting only the fixed state.

Rules and tiers: shared/src/scrub/rules.ts.

How long data is kept

Two retention systems exist, and they are not equally strong. This section says which is which.

The event stream is partitioned by day. A project's hot window defaults to 30 days and can be set between 7 and 90; past it, a day is archived to cold object storage and the table is dropped — not soft-deleted. Cold objects expire after a further window that defaults to 90 days (maximum 730; zero disables archiving). The pass runs hourly and drops by default (domain/src/modules/retention/, workers/src/retention/scheduler.ts).

Audit logs, spans, log records and replay segments are capped by plan — 30 days on Free, 90 on Pro, 180 on Team, 365 on Enterprise — and an organization can set a shorter window per stream. Deletion is implemented and tested, but the sweep has no scheduler: today it runs only when an administrator calls the enforce endpoint. A retention policy with an operator-triggered sweep is a weaker control than an enforced window, and a reader should treat it as one.

Erasure on request (below) is a stated policy rather than a blanket delete: nullable references to you are nulled, leaf rows are deleted, rows that other records depend on keep a pointer at a pseudonymized tombstone, and your user row is pseudonymized. Audit logs are retained, reduced to a principal id and a SHA-256 digest of their input — never raw payload. The code cites GDPR Article 17(3)(b) and (e) as its basis for that; the citation is the engineers' reading, not a legal determination, and this notice claims compliance with no regime.

Who else can reach it

No sub-processor agreement has been contracted with anyone, and there is no maintained sub-processor inventory. For transparency rather than as a list of obligations, the infrastructure the deployment runs on today is:

Audit events can additionally be streamed to a SIEM you operate, over an HMAC-signed webhook you configure; nothing is streamed anywhere by default.

Where it is stored

In one region, in the United States. Multi-region residency is implemented in the code — an organization in the wrong region is refused, and a migration path exists — but the EU control plane is marked inactive in the registry and does not exist, so no EU residency is offered and no DNS name for it is published.

How it is protected

The trust page is the full statement, with the file, test or endpoint behind each claim. In brief:

• In transit. A database connection to a host reachable off the machine, with no TLS material configured, throws rather than connecting in the clear; the material is held as text from encrypted secrets and is never written to disk. The dashboard sends HSTS and a same-origin content-security policy. Outbound calls from the API refuse private and loopback destinations.
• At rest. Our own secrets are encrypted in the repository (sops + age), and the guard that keeps them out of commits is a hash comparison, not a habit. Storage-layer encryption of the database and the object store is a property of the services we run on; we have not documented it and do not assert it here.
• Machines cannot approve or merge. Every AI agent acts as a principal under a named human sponsor; approving a fix is refused to non-human principals at three independent layers, and there is no merge method in the source-control client to call.

No SOC 2, ISO 27001 or other certification exists, no audit is in progress, and no third-party penetration test has been commissioned. The SOC 2 readiness note is an engineering self-assessment and should be read as one.

Your rights over your data

Access, portability and erasure are implemented as organization-scoped compliance endpoints, behind an administrator check, with the subject surface derived from the live foreign-key graph rather than a hand-kept list of tables — so a table added tomorrow is covered tomorrow (domain/src/modules/compliance/dsr.ts). Ask your organization's administrator to run one; the shape of erasure is described under retention above.

There is no self-service form yet, and no published address to send a request to. Both are gaps, and they are listed as such rather than implied away.

Cookies, analytics and this website

This website loads no analytics, runs no third-party script and sets nothing on your device that identifies you. It ships one small inline script and no other JavaScript, and a test in its source fails if a second one appears (code/website/src/lib/static-site.test.ts). That is not only a promise: the site sends a Content-Security-Policy that refuses to load a script, a style, a font or a connection from anywhere but this origin, so a third party cannot be added here by accident.

That script exists to read a single cookie. The dashboard at app.bucker.io keeps your session token in the browser's local storage, never in a cookie; but local storage cannot be read across hosts, so when you signed in the dashboard also set a cookie named bucker_session on bucker.io whose entire content is the character 1. It says that somebody on this device is signed in, and nothing else — not who you are, not which organization, and nothing that could be used to reach the API. Its only effect is that this site's header offers you "Dashboard" instead of "Sign in". It is cleared when you sign out, and expires by itself after thirty days.

The reason there is no consent banner in front of it is that it does nothing except remember something you did — signing in — and carries no identifier that could follow you anywhere. Whether that reasoning is sufficient under the ePrivacy rules is among the things counsel has yet to review, as the status line at the top of this notice says of everything here. If you would rather not have it, signing out removes it. The code that writes and reads it is code/frontend/src/lib/auth/session-hint.ts and code/website/src/components/session-hint.tsx.

Payments

No payment provider is connected. No card number, billing address or payment credential is collected by anything in this system, and nothing has ever charged a card. When that changes, this notice and the changelog change in the same commit.

Changes to this notice

Every change to this notice is a dated, reviewable revision, and the history is published alongside it. Material changes will be announced before they take effect.