Reference

Security and privacy

Black Hole holds two things worth protecting: access to your account, and the provider credentials you connect to it. This page describes, concretely, what protects each of them — and what Black Hole does and does not do with the content you create.

Account protection

Control	How it works
Breach-checked passwords	Every new password is checked server-side against a database of passwords exposed in public breaches. Matches are rejected outright.
Password strength	Length and composition are enforced on the server, so the rule cannot be bypassed by editing the page.
Two-factor authentication	Optional TOTP through any authenticator app, with one-time recovery codes stored only as hashes.
Login attempt logging	Successes and failures are recorded with time and network origin so unusual access is visible.
Rate limiting	Repeated failed attempts from one network trigger a temporary block rather than allowing unlimited guessing.

Turning on two-factor authentication

Open your settings, choose the security tab, and scan the code with your authenticator app. Save the recovery codes somewhere safe before you finish — they are the only way back into the account if you lose the device, and Black Hole stores only their hashes, so they cannot be recovered or re-shown.

Provider credentials

API keys you connect are encrypted with AES-256-GCM before storage. The encryption key exists only in the server environment. The stored value is authenticated ciphertext, so any tampering causes decryption to fail rather than silently produce a different value.

Decryption happens only inside the server, only for the duration of a build.
The interface shows a four-character hint, never the key.
No log line, error message, or support view exposes a full key.
Deleting a connection removes the stored record.

If a key is ever exposed

Revoke it in your provider's dashboard. That is the only action that invalidates a key everywhere. Deleting it from Black Hole removes Black Hole's copy but cannot invalidate copies elsewhere.

Data isolation

Every table holding user data enforces row-level security in the database itself. A query for someone else's projects, messages, or connections returns nothing, regardless of what the application code asks for. The rule is enforced at the storage layer, not by trusted application logic, so a bug in the app cannot leak another account's rows.

Administrative access

The administration console is not reachable from any link, menu, or navigation item. Opening it requires all three of: a signed-in account, an administrator role recorded in a dedicated roles table, and a fresh biometric verification — a face or fingerprint scan performed by your own device — or a two-factor code as a fallback.

Verification grants a session that expires after thirty minutes of inactivity.
Every entry attempt, successful or not, is logged.
Repeated failures block the network temporarily.
A signed-in session alone is never sufficient — role and fresh verification are both required.

What Black Hole does with your content

Your prompts and generated files belong to you.
Projects are private until you choose to publish them.
Content is sent to the model provider you selected, in order to fulfil your request, and to no one else.
When you use your own key, the provider's own data policy for your account applies to those calls.

Full terms are in the privacy policy and terms of service.

Reporting a vulnerability

If you find a security issue, report it privately through the contact address on the about page rather than posting it publicly. Include the steps to reproduce it. Reports are read and acted on.