How we handle your data.

01We never train on your data

The actions, inputs, and context you send are used for one purpose only: producing the forecast you requested. We do not use your data to train, fine-tune, or improve any model.

Forecasts run on Anthropic's API, which does not train its models on data submitted through the API. Your payloads are not sold, shared, or repurposed. For abuse monitoring, Anthropic may retain API inputs for up to 30 days before deletion; we don't hold your raw payloads anywhere beyond that.

02Encryption

• In transit: all traffic is TLS 1.2+ (HTTPS only; HTTP is 308-redirected to HTTPS).
• At rest: data is stored in managed Postgres (Supabase) with encryption at rest provided by the platform.

03API key security

Your API keys are never stored in plaintext. We keep only a SHA-256 hash; the raw key is shown to you exactly once at creation and is unrecoverable afterward. Each key is scoped to your account and can be revoked instantly from your dashboard.

Keys are the identity boundary: every request is attributed to the key that made it, and every forecast is tied to that identity.

04Decision receipts & cryptographic audit trail

Every forecast issues a cryptographically signed Decision Receipt — an Ed25519 signature over canonical SHA-256 hashes of the request body and the response body. The receipt envelope contains the hashes and the signature, not the payload itself.

What this gets you: anyone with the request, the response, and our published public key can verify offline that BLACK_WALL signed off on that exact (request, response) pair. No need to trust our servers, our logs, or our database. The receipt is the proof.

• Algorithm: Ed25519 over SHA-256 of canonical-JSON request and response bodies
• Public key: published at a stable URL — https://blackwalltier.com/.well-known/blackwall-signing-keys.json
• Verification: stateless endpoint at POST /api/v1/receipts/verify, or fully offline using any Ed25519 library
• Key rotation: receipts carry the key_id used to sign; retired keys remain published for verification of older receipts
• Row-level security: receipts are scoped to your account — you can read yours, no one else's, and the receipt envelope is immutable from your dashboard

Each receipt is paired with the forecast it certifies (verdict, risk score, red flags, gate, reversibility). Together they form a tamper-evident audit trail you can hand to auditors or regulators without exposing the underlying payload.

04.5The data we never see

The strongest privacy boundary is the data we never store in the first place. Black_Wall is architected so that raw request and response bodies are processed in volatile memory only and are never persisted to long-term storage, debug logs, or model-training pipelines.

• Forecast endpoint: request payload is hashed (canonical SHA-256), the hash lands in the receipt envelope, and the original bytes are released when the response is sent. No raw payload is written to disk, S3, or backups.
• Observability: structured logs capture timing, verdict, red-flag codes, and the receipt id — never the action body, the SQL string, the recipient address, or any other content field.
• Database: the forecasts table stores verdict metadata (action class, risk score, red flags, gate, latency) plus the receipt id — not the raw inputs the customer sent.

This is why receipt verification works offline: the customer already has the payload; we only ever had its hash.

05Data retention

What we store: verdict metadata (action class, risk score, red flags, gate, reversibility, timing), receipt envelopes (hashes + Ed25519 signatures), your account profile, API key SHA-256 hashes, and a token ledger.

What we never store: raw API keys (hashes only), raw request or response payloads (hashed and released), customer card data (Stripe holds that).

Receipt retention: free-tier receipts are retained 90 days; paid-tier receipts are retained indefinitely. Once a receipt is purged, the corresponding forecast metadata stays; only the signed envelope ages out.

Deletion: revoke any API key instantly from your dashboard (soft-revoked keys stop authenticating immediately). To erase your account and all associated records, email security@blackwalltier.com — we complete deletions within 30 days. Upstream, Anthropic purges API inputs on its own retention window (up to 30 days).

06Subprocessors

We use a small set of established infrastructure providers. We add no others without updating this list.

Sub-processor changes — adding, removing, or replacing — are reflected on this page within 30 days. Enterprise customers receive direct notice as part of their Data Processing Addendum.

07Self-hosting & open source

For teams that want to minimize the surface that touches a hosted service, we publish two open-source clients:

• blackwall-mcp — the MCP server. Runs locally (npx -y blackwall-mcp) so the only thing your agent host talks to is your own machine; the forecast call goes outbound from there. Source on GitHub · MIT.
• blackwall-sdk — the Python client. Zero dependencies (stdlib only). PyPI · MIT.
• Framework plugins (ElizaOS, OpenClaw, Hermes Agent) are all open source — see blackwall-eliza-guardrail, blackwall-openclaw-plugin, blackwall-hermes-plugin.

You can read every line that handles your data before it leaves your machine. Bug reports + supply-chain disclosures welcome at security@blackwalltier.com.

08Data Processing Addendum (DPA)

A one-page DPA template is available at blackwalltier.com/legal/dpa. It covers roles (BlueTier Operations as Processor; Customer as Controller), categories of data processed, the sub-processor list above, security measures, breach notification (72 hours), deletion on termination, and Standard Contractual Clauses for international transfer.

Enterprise customers can request a counter-signed copy at security@blackwalltier.com. We accept reasonable redlines.

09Certifications — where we honestly stand

10Reporting a vulnerability

Found a security issue? Email security@blackwalltier.com. We'll acknowledge within 48 hours and work with you on a fix. We don't pursue good-faith researchers.