Security

Our approach

This is an informational website with a small, deliberate footprint, and its security posture matches that reality. We describe only controls that are implemented. We claim no certifications, because we hold none, and we avoid grand security language, because it tends to describe marketing rather than systems.

As bnd's infrastructure grows beyond this website, the security measures will grow with it, and this page will be updated to describe what actually exists at each stage.

Encryption in transit

All traffic to and from this website is encrypted with HTTPS (TLS), provided and managed by the hosting platform, Vercel. There is no unencrypted route to the site.

How submissions are protected

Everything submitted through the forms is validated on the server before it is processed, which rejects malformed or oversized input. Submissions are forwarded by email to the founder rather than written to a database, so there is no stored pool of submissions to compromise.

The server applies rate limiting to prevent abuse of the forms, using short-lived keys derived from IP addresses. These are held in memory only and are never written to a database. Logging is kept to the minimum needed to operate the site.

What is deliberately absent

The most effective control on this site is what it does not have. There is no persistent user database, no account system, no stored passwords, and no analytics data. A breach of this website could not expose a store of user records, because no such store exists.

• No user database or account system
• No stored passwords or payment details
• No analytics or tracking data to leak
• No archive of submitted material held on the server

Secrets and dependencies

Credentials and API keys are kept in environment variables on the hosting platform, never in the codebase. The site's software dependencies are kept deliberately small, which reduces the surface where vulnerabilities can appear and makes updates easier to review.

Security during a data transaction

Everything above describes the informational website. A real data opportunity does not move through the public website forms. When an opportunity progresses, bnd must establish a transaction-specific process appropriate to the sensitivity of the material. For the first transactions, this may be a controlled manual process rather than an automated platform, and none of the stages below are automated today.

Discovery: high-level descriptions only; no raw sensitive data through public forms; supplier identity review; preliminary authority questions; risk and sensitivity classification.

Controlled inspection: explicit supplier approval; confidentiality terms; named reviewers; minimum necessary access; limited samples where possible; access start and expiry dates; package and version identification; material-access records.

Buyer qualification: a verified legal entity; identified representatives; a stated purpose; relevant technical capability; agreed confidentiality; prohibited-use terms; onward-transfer restrictions.

Delivery: an approved package; an approved destination; an encrypted transfer method appropriate to the transaction; integrity or checksum confirmation where appropriate; receipt confirmation; delivery date; named recipient; a retained transaction record.

Lifecycle: licence expiry; access suspension; retention obligations; deletion or return where required; renewals; disputes; incidents; closure.

The first bnd transaction can be governed through a controlled deal file containing the same essential records that may later be managed through automated Human Data Rail infrastructure.

Access and chain of custody

For every controlled package, bnd intends to know: who supplied it; who approved it; which version was inspected; who accessed it; what they were allowed to do; which buyer received it; when it was delivered; what licence governed it; when the rights expire; and what happened when the transaction closed.

The Governance and Chain of Custody page explains the full record that is intended to travel with every package.

Incident response

bnd does not operate a mature security operations centre today, and does not claim to. The intended response to an incident affecting a transaction is: suspend access where appropriate; identify the affected package; preserve relevant evidence; contact the affected supplier and buyer; investigate what happened; determine contractual and legal obligations; rotate credentials or revoke access where required; coordinate deletion, return, or remediation; and record the outcome.

Completed model training cannot always be reversed, and bnd does not promise otherwise. What is promised is that the response taken is recorded.

Reporting a security concern

If you find a vulnerability or notice something that looks wrong, report it to khaled@bnd.one. Reports go straight to the founder, and genuine reports made in good faith are welcome.

Please do not test suspected vulnerabilities against the live site beyond what is needed to identify them, and do not access or alter information that is not yours.