Privacy — B.E.N

The inventory

What is held

This list is the whole of it. If a category is not named here, B.E.N does not store it.

Account identity: Your email address and name. If you set a password, only a one-way hash of it is stored, never the password itself. If you sign in with Google, the account identifier, name and email address Google returns. If you sign in with Slack, the account identifier, name and email address Slack returns. Magic links are one-time tokens that expire.
Domains you control: Each host you add, the proof method used to demonstrate control of it, and the outcome of that check. A domain you added and never proved is still stored, marked unproven.
Site metrics: Domain rating, organic traffic estimate, topic, entity type, country and language, and the timestamp each figure was fetched. These come from public sources and third-party metrics providers, not from anything installed on your site. B.E.N does not measure your visitors and has no script to place on a page.
Pages: URLs discovered on your domains through your sitemap, with their title, placement kind and the number of outbound placements already on them. Public pages only, read the way any visitor reads them.
Your deal rules, goals, limits and prices: The deal rules and default floor for each site, the deal modes you are open to, any partner you have excluded, each site’s goals and limits, whether your agent may approve deals for it, and your prices if a site sells. These gate every offer, whether you or your agent makes it. Partners never see your rules or limits. Negotiation partners see the pages, placement types, exchange types and anchor style each site wants.
Messages: What you and your agent write in a negotiation or on a deal, and which API key sent each message. Both sides see the conversation.
Negotiations: Every offer and counter-offer, who made it (you, or your agent and which API key), each response, and each approval with whether a person or an agent gave it. A note your agent leaves for you on an offer is visible only to your company. The other side sees that an offer was drafted by an agent, never who approved it.
Vouches and disputes: Vouches you give, with any note; only your company can read the note. Disputes you raise, with the reason, the written decision, and who at B.E.N made it.
Activity: When you or your agent last used B.E.N, and which API key last checked for new activity. Partners you can trade with see when you were last active, rounded to the hour.
API keys: Each key’s name, a short prefix, its access level, and a one-way hash. The full key is not stored.
Exchange records: Every deal and every obligation within it: which domain gives, which receives, which benefits, the host page, the target URL, the agreed anchor text, the agreed rel value, the date promised, the current state, and when it first went live. For each deal decision, whether your agent made it and with which API key.
Verification evidence: For each automated check of a placement: the time, the HTTP status, whether the anchor was found, the href, rel and anchor text actually observed, where in the page the link sat, how many outbound links surrounded it, whether the page was indexable and self-canonical, whether the control fetch succeeded, and the resulting verdict. This is the record that makes a claim of delivery checkable, so it is kept in full rather than reduced to a yes or a no.
Trust events: The machine-verified events that move a company or domain reputation up or down, each tied to the obligation and the check that produced it.
Operational logs: Request identifiers, timestamps, endpoints and error types, kept so a fault can be traced from a report back to the request that caused it. Access tokens, credentials and full response bodies are never written to a log.

The deliberate part

Verification evidence is visible to both sides

When you enter an exchange, the evidence collected about that exchange is shown to the other party as well as to you. This is a design decision, not an oversight, and it is the reason the product works at all.

Why it has to be shared

An exchange is a mutual promise about a link. If only the party who made the promise could see whether it had been kept, the promise would be worth nothing and every dispute would be one person’s word against another’s. Shared evidence is what replaces trust with a fact both sides can read.

Exactly what the other side sees

Only the checks belonging to obligations in the deals you are part of: the timestamps, the observed href, rel and anchor, the surrounding link count, the indexability signals and the verdict. Your other domains, your other deals, your floors, your metrics and your account details are not visible to them (they do see when you were last active, rounded to the hour), and the database enforces that separation rather than the interface.

What a counterparty keeps

A completed exchange is a shared record of something two parties did together, so the other side keeps their copy of it. Removing your account does not delete their record of a deal they took part in, in the same way that closing a bank account does not erase the other end of a transfer.

Nothing is public

There is no member directory, no public profile and no shared list of participating sites. Everything behind sign-in is served with a header instructing search engines not to index it. That is a hard product rule: publishers in this market reject sites that turn up on public link-trading lists, so making members visible would harm the people it named.

The short list

What B.E.N never holds

No payment data of any kind. B.E.N records that an exchange was agreed and whether it was delivered. It never moves money, so it has no card number, no bank detail, no billing address and no payment processor account attached to your exchanges. If two parties settle something in money between themselves, that happens entirely outside B.E.N and leaves no trace in it.
No readable password. A password is kept only as a one-way hash. A magic link, Google or Slack sign-in needs none.
No visitor analytics. B.E.N does not run script on your site and cannot see who visits it.
No advertising or tracking cookies. The marketing site sets no cookie at all; the application sets only what is needed to keep you signed in.
No personal data scraped from crawled pages. The verifier reads a page to answer one question — is the agreed link present and in what form — and stores the answer, not the page.

Retention

How long each thing stays

Evidence outlives the deal it belongs to on purpose. A link exchange is a promise about something that must remain true for years, so a record that expired after ninety days could not answer the question the product exists to answer.

Your control

What you can ask for

Export

Everything held about you and your domains, in a machine-readable form, including the verification history behind every obligation.

Correction

Metrics come from third parties and are sometimes wrong. A corrected figure can be re-fetched, and the fetch timestamp shows how current any number is.

Deletion

Your account, your domains and their metrics are deleted. What survives is the counterparty side of exchanges you completed with someone else, because that record is theirs as much as yours.

Withdrawal

Removing a domain stops it being offered for new exchanges immediately. It does not retract obligations already agreed on it — those are settled with the counterparty, not unilaterally.

The rights you have, and the regulator you may complain to, depend on where you and the controller are. [TO BE COMPLETED — the statutory rights section, the lawful bases relied on, and the supervisory authority must be drafted by a lawyer once the controlling entity and its jurisdiction are settled.]

Agents

When your agent acts for you

B.E.N is designed to be driven by an AI agent over MCP. An agent connected to your account reads and writes as you, within the same boundary the interface uses.

An agent sees what you see and nothing more. The tenant boundary is enforced in the database, so a tool call cannot reach another company’s rows even if asked to.
What an agent may do depends on the key you give it: read only, propose and place, or autonomous. An autonomous key can do what you can do in the web app. It approves deals only if it may approve deals and the site allows it, and only inside your rules and limits. Managing keys and signing in stay with you.
Both sides approve every deal, as a person or through an agent its owner allowed to approve. When your agent approves a deal, the deal records that it did and which key it used. The other side is not told whether a person or an agent approved.
An agent cannot assert that a link is live. Placement state moves only on evidence from the verifier, so a claim of delivery from either side changes nothing on its own.
Whatever you send to your agent goes to whichever model provider you have chosen. That relationship is between you and them; B.E.N is not a party to it and does not see it.

Third parties

Who else is involved

Google — identity at sign-in, if you choose it. B.E.N receives an account identifier, a name and an email address. Google sign-in also asks for read-only Search Console access.
Slack — identity at sign-in, if you choose it. B.E.N receives an account identifier, a name and an email address.
SendGrid — sends sign-in links and account email. It receives your email address.
Metrics providers — queried for domain rating and traffic estimates for domains listed on B.E.N. They are asked about hosts, not about people.
Hosting and database — the infrastructure the service runs on.
The public web — the verifier fetches agreed host pages as an ordinary visitor, identifying itself honestly in its user agent and respecting a per-host rate limit.

[TO BE COMPLETED — the named sub-processor list, their locations, and the transfer mechanism relied on for any transfer out of the region the controller is established in.]

Contact

Who is responsible for this data

[TO BE COMPLETED — the legal entity acting as controller, its registered address, its company number, the contact route for privacy requests, and a data protection representative if one is required. Nothing on this page should be published with these fields unfilled.]

B.E.N — last updated 14 September 2026. Material changes will be announced in the application before they take effect.

What B.E.N knows