Security model

This page states what MasterDB guarantees, and just as plainly what it does not. Read “What MasterDB does not claim” as carefully as the guarantees. Every guarantee here can be checked with public data and the open-source verifier libraries.

What MasterDB is, for this purpose

Verified businesses publish records — products, Business & Brand files, events, jobs, updates, and their AI policy — each sealed over its exact bytes. AI companies retrieve them with signed requests, and MasterDB answers with index rows it has signed, records exactly as sealed, and a signed receipt. Certificates, keys, projection specifications and a transparency log are public, so everything MasterDB serves can be checked without trusting MasterDB.

What MasterDB guarantees

1. Nothing MasterDB delivers can carry instructions beyond the business that published it. Every record is bound to its author by its seal, and publishing refuses text that names another company or brand the business does not own or sell, or that directs how other sources should be treated. A record can speak only for its own business.
2. What MasterDB delivers can be checked without trusting MasterDB: a record against its seal, a row against the published projection, a receipt against MasterDB’s published keys, all chained to pinned trust anchors, with open-source verifiers and public test vectors.
3. MasterDB cannot forge the seal of a business that holds its own key. A business that seals with a person’s passkey or its own integration key holds the only private key. A business that uses hosted signing asks MasterDB to sign for it: MasterDB signs only after a person at the business has confirmed the exact request. Such a seal proves that MasterDB signed on a request a person confirmed, not that the business alone could have produced it. MasterDB’s signed key custody statement says, for every key, whether it is hosted or self, and a verifier can read it.
4. MasterDB cannot forge an AI company’s request. It holds only the public half of every retrieval key; every billable request carries the company’s own signature, and every receipt is bound to it.
5. MasterDB cannot quietly rewrite what it asserted it served. Receipts, seals, key events and certificate issuances are folded into an append-only transparency log. Anyone who keeps two checkpoints can ask for the consistency proof between them (GET /v1/log/consistency) and see that nothing was edited or removed.
6. MasterDB does not rank. A search has no default order; the caller names the sort. There is no ranking mechanism to turn.
7. A blocked AI company is not told, anywhere on MasterDB’s authenticated surfaces (see the limits below).

What MasterDB does not claim

• MasterDB does not stop prompt injection in general. Binding every record to its author means text cannot reach beyond its author — and that is all. A business can still publish text that attempts to instruct an AI about its own products, and MasterDB cannot make an AI ignore it. Defending a model against the content it reads is the AI company’s work.
• MasterDB does not see what an AI company does after retrieval, and cannot prove an answer was faithful, or that data was not cached or reused. Those controls are contractual, not cryptographic.
• MasterDB cannot technically stop an AI company training a model on what it retrieved. The AI-company Terms, which every AI company accepts before it receives a production key, forbid training on the data, caching it for reuse, and using it beyond one conversation. And every delivery is attributable: each request is signed by the company’s own key, each response carries a receipt bound to that key, and the receipts are in the transparency log. A record, or a distinctive price or phrase from one, found in a model’s output or a training set can be traced to the company it was served to and when. A breach is detectable and provable after the fact, and actionable under the Terms.
• MasterDB is not in the payment and cannot say a purchase went right.
• A seal proves who published bytes and when; it does not prove the bytes are true.
• Verification raises the cost of impersonation; it does not make impersonation impossible. It is not an endorsement of what a business publishes.
• A signed message from an AI company proves which company sent it; it does not prove a person asked for it.
• A receipt proves what MasterDB asserted it served; it does not prove the response arrived.
• A block is hidden on MasterDB’s surfaces — and only there. MasterDB therefore offers no completeness proof. A company that compares results with another company, reads a business’s own website, or presents a record it already holds to the public verify endpoint could infer a block. Blocking does not recall what was retrieved before it.
• Image-fetch counts are a lower bound on renders, not an observation of every render.
• Deletion means deletion. After a business deletes a record, MasterDB keeps its fingerprints — hashes, log leaves, receipts and billing rows — not its bytes. MasterDB can show that a record with a given hash was live at a given time and to whom it was served; only someone who kept the bytes can show what it said.
• Action terms and blocked contexts are honoured by the AI company. A business’s purchase: false, or a context it blocks, binds an AI company under the Terms; nothing cryptographic stops a system that ignores it.

Protections, and the limit of each

A dishonest business

Wants: to publish a claim about another company, an instruction aimed at AIs, a false price or a false identity.

Protection	Limit
Scope check at publish: text naming a company or brand the business does not own or sell, or directing how other sources are treated, is refused. Names are matched after Unicode normalisation, case folding and folding of look-alike characters. Claiming another business’s registered brand as one’s own is refused.	Matching is on names: a paraphrase that names no one passes.
Plain text only, role addresses only in any published contact, strict JSON, size and character limits, unsafe URLs refused, and every URL checked for known malware and phishing at publish and daily after.	A legitimate domain compromised later is caught by the daily re-check, not at once.
Every record sealed to a verified legal identity: attributable, revocable, and its history stands.	A seal makes a false claim attributable; it does not make it true.
Verification of the legal entity before it publishes.	See “What MasterDB does not claim”.

A dishonest AI company

Wants: to copy the corpus, under-report renders, over-report clicks, dispute its bill, or learn who blocked it.

Protection	Limit
No bulk path: no list, no export, no batch fetch, at most 50 rows a search and no second page; every search and fetch is billed. The public verify endpoint needs the record itself, never a bare id.	A company willing to pay can still walk a catalogue fifty rows at a time; that is bounded by cost, not prevented.
Every request signed by the company (non-repudiable); every response carries a signed receipt; the bill is the receipts.	—
Renders observed by image fetch; clicks measured across companies.	Fetch counts are a lower bound; fraud is detected by ratios, not proven per event.
Blocks are invisible by construction: identical 404s, no field, count or aggregate anywhere, no completeness proof.	See “What MasterDB does not claim”.
The Terms and each business’s AI policy bind contractually, and the receipts give the evidence.	Enforcement is contractual, after the fact.

A third party with a stolen business credential

Wants: to publish in the business’s name.

Protection	Limit
Passkeys cannot be phished (bound to MasterDB’s domain), and a device-bound passkey cannot be exported. A business can require device-bound passkeys.	A synced passkey is as safe as the account that syncs it.
An integration key needs a mandate: sealed by a person’s passkey, scoped to record types and countries, at most 92 days, with per-key caps and an optional source allow-list. A per-key sequence number stops a stolen key replaying an older seal to roll a price back. The price-shock hold stops a push that moves a fifth of a catalogue’s prices until a person confirms it.	A thief with a live key and mandate can publish inside the mandate’s scope until the key is revoked.
Revocation with an effective moment invalidates what was sealed after it, and nothing before.	—
A confirmation email on a separate channel (to every owner and admin, naming the person, each time a person publishes, withdraws or deletes a record in the portal) exposes misuse within minutes. A push through the API sends no email for each product; the business’s developers are emailed at once only when a push needs a person.	Detection, not prevention.
An email-only session can do nothing sensitive; editing a draft on a verified business needs a fresh strong sign-in; recovering a lost passkey is followed by a 72-hour cooling period before the new passkey can seal.	—

A third party with a stolen AI-company key

Wants: to query at the victim’s expense.

Protection	Limit
Signed requests with a five-minute window and single-use nonces cannot be replayed; each signed request is billed once.	A thief holding the private key can sign new requests until it is revoked.
Per-key rate limits and cost budgets; revocation fails closed in every region within seconds.	—
The victim’s receipts and its own reconciliation expose use it did not make. Liability sits with the party whose key it was, as the Terms state.	—

A network attacker

Wants: to alter data in transit, or replay it.

Protection	Limit
TLS 1.3 only, with a hybrid post-quantum key exchange; every request signed with its body’s digest covered; every row and receipt signed; records verifiable against their seals.	—

A denial of service

Wants: to take a region down, or drain a business’s ad budget with fake demand.

Protection	Limit
Edge throttling and a web application firewall; regional failover; per-key limits; ad reserves released when their window expires; an ads pool is a signed request from a known key, so an unknown caller never reaches a budget. The public verification surface is never rate-limited so as to block a checker.	Availability is engineered, not guaranteed.

A compromised MasterDB service

Wants: to forge seals, receipts or rows.

Protection	Limit
MasterDB holds no AI-company private key, so it cannot forge a request, and no private key of a business that holds its own, so it cannot forge that business’s seal.	A hosted key is held by MasterDB, and its key custody statement says hosted.
Every use of a hosted key and every certificate issuance is recorded in the transparency log and reconciled against MasterDB’s own signing records.	Detection, not prevention.
MasterDB’s working keys (projection, receipt, sidecar, statement) are rotated every 30 days, certified by an issuance key, and can be marked compromised from a moment, which verifiers apply.	A forged row or receipt is possible within one working key’s window, until detected.
Every issuance, seal and minute of receipts is in the transparency log.	—
The root key lives in a hardware security module and is used only in a recorded key ceremony. Its anchors are pinned in both verifier libraries. Every long-lived artefact also carries an ML-DSA-65 signature, and the verifier libraries require both.	—

A compromised portal build

Wants: to make a person seal bytes they did not see.

Protection	Limit
A content security policy with subresource integrity on every script; the diff since the last publish on the save screen; the confirmation email to every owner and admin, with a link to the record in the portal.	Detection within minutes, not prevention.

The software supply chain

Wants: a malicious dependency in a portal or a service.

Protection	Limit
Lockfiles with provenance, dependency review, a minimal dependency policy for the sealing path, and container images built from pinned lockfiles and admitted only with a build attestation.	A dependency compromised upstream before it is pinned is not caught by pinning.

A compromised MasterDB staff account

Wants: to alter records, approve a fraud, or export data.

Protection	Limit
Staff tools behind multi-factor sign-in; one endpoint per action, no generic edit; every action audited before it takes effect, with alerting; no bulk export and no direct database access.	Detection, not prevention.

A regulator or a court

Wants: evidence.

Protection	Limit
The same artefacts as everyone else — receipts, seals, certificates, the transparency log and evidence packs — with no special path.	After a deletion, only fingerprints remain.

MasterDB itself, in the future

Wants: to rank quietly, or edit history quietly.

Protection	Limit
There is no ranking mechanism to turn a dial on; the projection specifications are public, versioned and re-runnable, so anyone can check a row against its record. History cannot be edited without the log showing it.	A future MasterDB could change the software; it could not change what was already logged without it showing.

Cryptography

Purpose	Algorithm
Business seals made with a passkey	ES256, or RS256 where the device makes only RSA keys — a WebAuthn assertion either way
Business seals made with an integration key, AI-company request signatures, MasterDB’s row, receipt and checkpoint signatures	Ed25519
Seals made with a hosted key	ES256; the key custody statement says hosted
MasterDB’s root and issuance keys	ECDSA P-256, held in a hardware security module, plus ML-DSA-65
Long-lived artefacts’ second signature	ML-DSA-65 (the verifier libraries require both signatures of key certificates, ADL Certificates, key custody statements and the key set)
Hashing	SHA-256
Envelopes	DSSE with a typed payloadType per artefact; the algorithm comes from the key register, never from the envelope
Request signing	RFC 9421 with RFC 9530 Content-Digest
TLS key exchange	hybrid X25519 + ML-KEM-768

No JSON canonicalisation on the API path: MasterDB signs and stores the octets it received. The portal path uses a canonical form MasterDB defines at both ends.

Reporting a security problem

Use the contact form on masterdb.ai/contact (see Support) and say it is a security report. Please give MasterDB a chance to fix a problem before you publish it, and test only in the sandbox, never against production businesses’ data.