Privacy policy. ScoutBridge.

Who this is from

ScoutBridge is sold to accelerators and is used by their staff and by the founders in their cohorts. An accelerator decides what goes into its own workspace and who may see it. ScoutBridge holds and processes that material in order to run the service, and for nothing else.

ScoutBridge is operated by SLVR Partners LLC, a limited liability company registered in the State of Delaware, United States, with its registered address at 230 Kings Highway E, Suite 350, Haddonfield, New Jersey 08033, United States. ScoutBridge is offered to businesses in the United States and this policy is written for United States law. It describes what the system does and makes no claim about which other regime it satisfies.

What the service holds

The categories below are the whole of it. Everything is held per accelerator, and no accelerator can reach another’s records.

Accelerator staff accounts. An email address, a display name, the accelerator the account belongs to, and what that person is allowed to approve.
Founder accounts. An email address and the company the founder is attached to.
Company application material. What a founder submits, the original artefacts exactly as they arrived, the fields read out of them, any contradictions found between them, and the readiness assessments written from them.
Investor records and thesis data. Funds, the partners at them, what each fund invests in as stated and as observed, the history of an accelerator’s relationship with each one, and publicly filed fund information.
Introductions and decisions. Scored pairings, the case for and against each one, drafts, the approval or refusal with the reasoning the person typed, the record of what was transmitted, and any reply that is later recorded against it.
Operational records. An append-only audit log, the job queue, how long a reviewer spent on a decision, and the spending limits that stop automated work.
Connected credentials. Where a partner has connected a mailbox, a sealed refresh token and the mailbox address it belongs to. Where an accelerator has connected Slack, a sealed bot token.

Four things are worth stating by their absence. The service holds no payment card details and has no payment integration of any kind. It takes no custody of funds or securities. It does not build a profile of any individual investor from outside sources. It holds no founder demographic attribute anywhere in its schema and uses none as a scoring signal.

Google user data

A partner may connect their own work mailbox so that introductions they approve leave under their own name. This section describes that connection in full.

One permission, and it cannot read mail. The only Gmail permission ScoutBridge requests is https://www.googleapis.com/auth/gmail.send. Alongside it the service requests openid email, which exist only so that Google can be asked which mailbox a new grant belongs to. No read permission is requested. There is no code anywhere in the service that lists, opens, searches, downloads or stores a message from anybody’s mailbox, and there is no permission held that would allow it.

What it is used for. Sending one introduction email that a named person at the accelerator approved individually, in the product, before it was sent. Nothing is sent in bulk. Nothing is sent automatically. An approval by a named human is required by the database itself, which is why it holds even when application code is wrong.

Whose mailbox it sends from. The send request addresses the account the access token belongs to and never names a mailbox, so there is no field in it that another person’s address could be put into. When a partner first grants access, Google’s own identity endpoint is asked whose account it is. If the answer is not the mailbox the connection was started for, the credential is discarded rather than stored.

What comes back from Google. The identifier Google returns for the message it accepted, which is stored against the record of that transmission, and the mailbox address from the identity check. Nothing else from any Google API is retained.

Replies do not come to us. An introduction carries a reply-to address that is the partner’s own address with a tag added to it, so when an investor replies the message goes to that partner’s own inbox. ScoutBridge has no mechanism that reads a reply out of a mailbox and no permission that would let it. An outcome is recorded against an introduction only where a reply has been supplied to the service, and the service cannot go and fetch one.

How the credential is stored. The refresh token is encrypted with AES-256-GCM before it is written and is bound to the accelerator, the person, the provider and the mailbox address, so a copy of it moved onto another record will not decrypt. The key is held in the environment of the process that sends and is never stored in the database. Browser sessions run as a database role that has no permission on the credential columns at all, so an attempt to read one produces an error rather than a value. Stated honestly, this protects against a compromise of the database on its own. It does not protect against something that reaches the running process or the machine it runs on.

How a partner revokes. Disconnecting inside the product deletes the record and the sealed token with it. This is the only destructive action any signed-in session can take anywhere in the system, and it exists so that a partner can end the arrangement themselves. A partner may also revoke access directly in their Google account, at myaccount.google.com/permissions. Either route ends the ability to send.

Limited Use

ScoutBridge’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In concrete terms, the information received from Google APIs is used only to send an introduction a user approved and to confirm which mailbox it sends from. It is not transferred to any other party, it is not used for advertising, it is never used to train a model, and it is not read by a person except where a user asks for support, where it is necessary to investigate abuse or a security incident, or where the law requires it.

A partner’s own mail provider

When an introduction is sent, it travels through the partner’s own Google Workspace or Microsoft 365 account under the grant that partner gave. That is the partner’s existing relationship with their own provider rather than ScoutBridge passing data to a vendor of its own, which is why neither provider appears in the list below. Their handling of the message is governed by the agreement the partner or their employer already has with them.

Who else receives anything

These are every third party that receives customer data, and what each one gets. Adding another without naming it here fails this repository’s own build.

Supabase the managed Postgres database and the authentication service: Every record the service stores. That includes accounts and the email addresses attached to them, company application material, investor and thesis records, approvals and the reasoning a human typed with them, the audit log, and the sealed mailbox credentials. Supabase Auth also holds the password verifier for every account.
Vercel hosting for the web application and for the scheduled jobs that run the work loop: Every request the application serves passes through it, along with whatever request logging the platform keeps. Application data itself is not stored there.
Anthropic the model provider whose inference the service depends on: Company application material and the text extracted from it, readiness assessment inputs, investor thesis material, the facts an introduction draft is written from, and the body of a reply an investor sent to a partner. This is the substantive content of the product and it is sent as the prompt of an ordinary API call. No mailbox address, no account credential and no stored token is ever part of one.
xAI the search provider used to find the published writing of an investor, only when a partner runs the discovery command against a named handle: The public X handle of an investor or firm being researched, and the date window being read. Nothing else. No company application material, no founder, no account, no approval and no stored token is part of one of these requests. What comes back is the public posts of that investor, which a person reads before anything is recorded.
Slack an optional surface for working the approval queue, only once an accelerator connects a Slack workspace: A card naming the company, the approvable it concerns, the name of the partner whose mailbox an introduction would leave from, how long it has been waiting, and a link back into the product. The card carries no investor identity, no draft text and no readiness narrative, and it is delivered to one named person directly rather than to a channel.
Calendly the booking page that opens when a visitor chooses to book a call from the public site, only when a visitor books a call: Whatever a visitor types into the booking form, usually a name, an email address and a chosen time. ScoutBridge does not receive or store any of it. Nothing loads from Calendly until the visitor presses the button.

The application runs in a United States region, and the deployment procedure requires the database to be created in one. Anthropic receives the substantive content of the product, which is the answer an accelerator most often wants, so it is worth being exact. The material a founder submits and the investor material an accelerator holds are sent as the prompt of an inference call, because reading a deck and writing a draft is what the service does. Credentials, tokens and mailbox addresses are never part of one.

How long it is kept

The retention period configured for this service is 2555 days, which is seven years, measured from the point a record is written. That figure comes from the operating profile the service runs under rather than from a choice made in this document.

Two things about it are worth saying plainly. Deletion at the end of that period is not yet automated, so a record removed today is removed because somebody asked and somebody acted. And the audit log is append-only with a hash chain over it, which means an entry in it cannot be edited or removed without breaking every entry after it. The audit log records the shape of an action rather than the secret inside it, which is why no credential is ever written to it.

A connected mailbox credential is the exception and is not kept on that schedule. It is deleted the moment a partner disconnects.

How it is protected

Every table holding customer data has row level security enabled and forced, with a policy that filters both what a session may read and what it may write. Forced matters because it applies to the owner of the table as well. The role all automated work runs as cannot bypass those policies and is not a superuser, so it cannot see across accelerators even in principle.

ScoutBridge does not store or verify passwords itself. Sign-in is handled by Supabase Auth, which holds the password verifier. A password typed into the sign-in form is passed straight to that service and is never written to the ScoutBridge database and never logged.

A fuller security posture document, including what this design does not protect against, is available on request to the address below.

What the service does not do

It does not sell data. It does not serve advertising and holds no advertising or analytics tracker. It does not share one accelerator’s data with another. It does not use customer data to train a model. It performs no automated inference or profiling about an investor who is a natural person from outside sources, which is enforced by the shape of the database rather than by a policy somebody remembers.

Requests and questions

A founder or a member of staff who wants to know what the service holds about them, to correct it, or to have it removed should ask the accelerator whose workspace it sits in first, since the accelerator decides what goes in. Requests may also be sent to the address below and will be passed on where ScoutBridge is not the right party to answer them.

We respond to a verified request within forty five days. If we need longer we will tell you why before that period ends.

Children

The service is sold to organisations for business use and is not offered to anyone under eighteen. ScoutBridge does not knowingly hold data about a child.

Changes

This page changes when the system changes. The date at the top is when it last did. Where a change materially alters what happens to data already held, ScoutBridge will tell affected customers rather than rely on the date alone.

Contact

Questions about this policy, and requests about data, go to mark@slvr.ag.