The short version
Isolation between clubs is structural, not a policy setting: every conversation belongs to a membership at one club, and no query shape reaches another club's rows.
Your roster is the source of truth. Members never create accounts and never hold passwords — they prove a mailbox, and their standing comes from your export.
The concierge answers only from what you gave it, treats everything it reads as untrusted text, and hands the member to your staff rather than guessing.
We keep the minimum, encrypt it at rest and in transit, and write an append-only audit record for every change your staff make and every time we look at a member on your behalf.
We have no SOC 2 report and no third-party penetration test. What we have instead is on this page, in detail, including the parts that are unfinished.
17 controls, four honest states
Most trust pages show a wall of green checks. This one uses four states, because 4 of ours are not green — and a club's IT review is faster when the gaps are named up front rather than found later.
One club cannot reach another
The question every club asks first, and the one where a policy answer isn't good enough.
A club cannot reach another club's data, and cannot learn which other clubs a member belongs to.
- A person is one row globally; a membership is that person at one club. Every member-facing record hangs off the membership, and a conversation's membership is a non-null foreign key — there is no transcript without a member behind it, at exactly one club.
- Everything club-owned is read through the current club's own associations, explicitly, at every call site. There is no default scope to forget, and no record's owning club is ever inferred from a URL.
- The club identifier in the address bar authorizes nothing on its own. Access comes from a membership or a staff assignment looked up in the requester's own records.
- A person's list of clubs is unreachable from any club or staff context. If a member belongs to three clubs, none of the three can learn about the other two.
- Five hosts, with separate sessions and separate gates: members, club staff, BagDrop operators, a host for machines posting signed payloads, and this one. Cookies are host-only.
Members hold no passwords
There is no self-service signup anywhere in the product. Your roster decides who exists.
- A member signs in with a six-digit code or a link from an email: ten minutes, one use, five guesses, and bound to the browser that asked for it — so a forwarded code is inert.
- Continue with Google verifies the token's signature against Google's published keys and every claim separately. It only ever binds to an account your roster already contains, on a verified address, and it never creates one.
- That Google binding is cut the moment the account's email changes, when a password is reset, and whenever the owner disconnects it from their own page — so a mailbox someone loses control of cannot keep signing in as them.
- Staff and operators use a password or Google, with rate limits on every sign-in endpoint and constant-time comparison throughout. A staff sign-in link issued by a colleague reaches one club, once, for a week, and is audited when used.
- Removing a staff assignment revokes that person's staff sessions immediately. A departing employee is signed out, not merely un-listed.
What the model may see, and may do
The section a board in 2026 reads first, and the one most vendors answer with a sentence.
It answers from your knowledge only, and everything it reads is fenced off from its instructions.
- Every retrieved passage, past conversation, preference, newsletter section and document excerpt is wrapped in a per-turn random marker before it reaches the model, with instructions that text inside the marker is reference material and never an instruction.
- A newsletter is trusted only as far as its DKIM or SPF alignment proves the sender. Anything applied from one that no staffer has read is delivered separately, marked unverified, and never as the club's own word.
- If the knowledge base doesn't cover a question, the concierge hands off to your staff rather than answering. A confidently wrong answer about a guest fee costs a club more than "let me check with the team."
Today the concierge writes nothing into any club system.
- BagDrop is in its information phase: it answers questions. It does not book tee times, hold dining tables, take payment or change anything in your tee sheet, POS or member database. Nothing it does can create an obligation for your club.
- Tools are the only way the model can act at all, and every tool reads and writes through the conversation's own club and membership — never an identifier the model supplied. There is nothing for it to leak by construction.
- When write actions arrive, they arrive with per-turn budgets, one call per turn for booking or cancelling, and a club-provisioned service account that is encrypted at the column, never displayed back, revocable in one click, and limited to a closed list of verbs with no script execution.
We measure the answering, not only the retrieval.
- Most of what keeps a member safe is written in the concierge's instructions rather than in code — so we run a 34-case suite against the live model, across 7 arms covering grounding, refusal, disclosure, prompt injection, booking restraint, memory and hedging. It runs before any change to those instructions ships.
- Across every run to date, no run has produced a wrong fee, a wrong rule, or a fact the corpus does not contain. The failures we have recorded are the concierge deferring too little or overstating what it had done — both of which we hold as red rather than relax.
- Read the size before the score: 34 cases is enough to catch a change that breaks something, and nowhere near enough to certify a concierge. We would rather say that than quote a percentage.
What actually leaves for the model, each turn.
- Sent: the club's published knowledge, the passages retrieved for the question, the member's display name, their stated preferences, a short summary of what the club has done for them, and the last twenty turns.
- Not sent: the member's email address, phone number or member number. No billing data — we hold none. No other club's anything.
- The provider is Anthropic's commercial API, whose terms exclude training on customer inputs and outputs. There is no BagDrop model being trained on anything.
- Embeddings and voice transcription run in-process on our own machine. Dictation audio is deleted inside the request that transcribed it and is never stored.
What we hold, by class
Everything BagDrop stores about a member or a club. Nothing off this list exists.
| Class | Fields | Source | Who sees it |
|---|---|---|---|
| Person | name, preferred name, email, phone | your roster export | the member; your staff; our operators |
| Membership | member number, category, status, joined date | your roster export | the member; your staff; our operators |
| Directory profile | town, region, employer, profession, birthday, spouse, children, interests, photo — each field shown only where your own export flagged it visible | your directory export | other members of your club, under your club's own permissions; your staff |
| Conversations | member, concierge and staff turns; tool calls; a one-line subject per conversation | the member, at your club | the member; your staff; our operators; Anthropic per turn |
| Preferences | stated by the member, or entered by your staff — staff-entered ones stay club-local until the member elevates them | the member; your staff | the member; your staff; the model per turn |
| Club knowledge | facts, uploaded documents, fetched public pages, the weekly newsletter, events, closures, hours | your club | members according to visibility; your staff; the model |
| Vendor credentials | a service-account secret you provisioned, encrypted, with a record of who at your club authorized it | your club | nobody — used by the automation, never displayed |
| Sessions and push | IP address, user agent, browser push endpoint | the device | our operators |
| Not held | member passwords · payment or billing details · live balances or statements · dictation audio · any club's data inside another club's context | ||
Every third party that receives data
The complete list, all 5 of them. We will give a club thirty days' notice before adding one.
| Processor | Receives | Purpose | Note |
|---|---|---|---|
| DigitalOcean |
everything, at rest | server, managed database, object storage for uploads, encrypted queue replica, archive storage | single region; database and object storage encrypted at rest by the provider; daily backups and point-in-time recovery |
| Anthropic |
per turn: club knowledge, retrieved passages, member display name, preferences, service summary, recent turns | the model behind the concierge | commercial API; inputs and outputs excluded from model training under Anthropic's terms |
| MailerSend |
member name and email for sign-in and notification mail; your newsletter inbound | transactional email and newsletter routing | inbound webhook signed with HMAC over the exact body |
| Google |
sign-in identity where a member or staffer chooses Google; IP and user agent when a page loads fonts | Continue with Google; web fonts | the only request a member's browser makes to anyone but our own infrastructure provider |
| GitHub |
source code and the container image | source hosting, CI, image registry | no member data; the image carries encrypted credential files only |
| Not used | no analytics or tracking scripts · no advertising or marketing pixels · no external embedding or transcription service · no CDN in front of member pages · no data broker, ever | ||
Where it runs
One managed database off the box, one box, both encrypted, all in a single US region.
- TLS everywhere with HSTS. Member and club data lives in a DigitalOcean managed Postgres cluster in New York, encrypted at rest by the provider, with daily backups and point-in-time recovery.
- The operational stores on the server — job queue, cache, error log — sit on a LUKS2-encrypted volume. Uploaded documents and photos are not on the server at all: they live in object storage in the same region, reachable only through links that expire.
- A club's own vendor credentials are encrypted at the column level, cannot exist without a record of who at the club authorized them, and are never readable back — not by staff, not by us.
- No secret has ever been committed to the repository. Keys live in encrypted credential files, and the git history has been checked for this specifically.
- A club that wants stronger separation can have a dedicated instance: its own server, database, backups and keys. The product is one deploy against one database, so this is a commercial choice rather than an engineering project.
How each store is backed up, and who holds the key
Not one answer but four, because they genuinely differ — and the difference a reviewer cares about is who holds the key, so that is a column rather than a footnote.
| Store | How it's backed up | Key held by | Recovery point |
|---|---|---|---|
| Postgres — members, conversations, facts, vectors | DigitalOcean managed cluster: daily backups and point-in-time recovery, encrypted at rest by the provider | DigitalOcean's | the cluster's PITR window |
| Job queue replica | Litestream to object storage every minute, age-encrypted on the host before upload | ours — the age identity, held offline | about one minute |
| Uploads — handbooks, portraits, newsletter sources, logos | held in object storage in the same region, encrypted at rest by the provider and reachable only through expiring signed links; copied nightly to a separate bucket, AES-256-GCM on our own host before it leaves | the provider's for the store itself; ours for the nightly copy | the object store; 24 hours for the second copy |
| Operational stores on the server | LUKS2 volume, unlocked on boot; protects a stolen disk or a leaked snapshot, not someone with root on the running box | ours — on the box, because the volume must unlock unattended | covered by the queue replica |
Every backup we make ourselves is encrypted on our own host before it leaves — the queue replica and the nightly copy of your documents — so those buckets hold ciphertext and nothing else. The stores themselves are a different answer: the managed database and the object storage holding uploads are both encrypted at rest by DigitalOcean, under DigitalOcean's keys, and we hold no key that would let us decrypt them independently. That is the ordinary arrangement for managed infrastructure, and it is the same arrangement for your members' conversations as for their club's handbooks — we would rather be consistent about it than claim a stronger guarantee for the documents than for the transcripts. A club that needs the stronger one should ask about a dedicated instance with its own keys.
What ages out, and when
A window marked like this is read from the constant the nightly sweep actually uses, not typed into this page. Change the code and this table changes; there is no second copy to forget.
| What | Kept for | Counted from | How it's enforced |
|---|---|---|---|
| Conversations | 12 months | the end of the membership | nightly sweep, once the roster marks a member lapsed or resigned |
| Roster record, profile, preferences, push subscriptions | 30 days | your export dropping the member | nightly sweep |
| A member who asks to be deleted | 7 days | the request | out of the product at once; erased after the grace window, with a suppression record so your next export does not resurrect them |
| Inbound newsletter, raw | 1 day | routing and reading it | incinerated on schedule, not the 30 days the mail framework would keep by default |
| Uploads archives offsite | 30 days | the archive being written | pruned on each nightly run, which is what keeps the privacy policy's backup window true |
| Document links | 6 days | issue | signed URLs expire; a roster upload file is purged once imported |
| Audit events | 7 years | the event | kept by policy — never updated or deleted, and a member's identity within them is redacted to a token on erasure |
Audit, and who at BagDrop can see what
Every staff and operator mutation writes an append-only record.
- Facts, documents, hours, closures, roster imports, member profile edits, staff sign-in links, integration credentials, club settings, every sign-in and sign-out, and every feature-flag change — each writes an audit event with actor, IP address and request identifier. The table is never updated and never deleted from.
- Directory lookups, where a club enables the directory, are audited on every attempt including the refusals, mirror your own directory permissions, never widen them, require the asking member to be in good standing, and are capped per day.
- A club's staff console gates on named capabilities rather than job titles, so what someone can do is visible on one page and revocable there.
3 named operators can read member conversations. We would rather say so than imply otherwise.
- Access is through a SQL console running on a read-only database role with a statement timeout, and every query is recorded. The alternative route is being assigned as staff at your club — which appears on your own team page, where you can remove it.
- There is no encryption on the shared fleet that hides transcript content from us. Almost no vendor in this category can honestly claim otherwise; a club that needs that guarantee should take a dedicated instance with its own keys, and we will put the operator access policy and audit review in the contract.
How the software is built
With no SOC 2 report to hand you, this is the evidence we do have — and it's more specific than a badge.
Every commit passes four gates before it can merge.
- Static security analysis of the application, a check against known vulnerabilities in every Ruby dependency, the same for JavaScript dependencies, and the full test suite. A failure blocks the build; there is no override.
- Deployment runs from a pinned pipeline to a single host whose SSH host keys are pinned rather than trusted on first use.
The security invariants are tests, not documentation.
- Five invariants sit at the top of the repository — tenant scoping is explicit, a conversation belongs to a membership, a person's other clubs are unreachable, the concierge answers only from supplied context, and staff-entered preferences stay club-local until the member elevates them. Each is enforced by specs. A change that breaks one fails the build.
- An architecture decision record is written in the same change that makes the decision, so the reason a control exists is recoverable years later. This page cites them by number throughout.
A full adversarial review, and what it found.
- On 4 September 2026 the whole application was reviewed against an attacker's goals rather than a checklist. It produced 34 findings: 3 high, 16 medium, 15 low.
- All 3 high findings were closed within three days, along with 14 of the 16 mediums and 12 of the 15 lows. 2 lows are partly closed and 1 — pinning container image digests — is deferred as the lowest-value item on the list.
- The 2 mediums left open are a deliberate design decision on session lifetime and a second-reviewer requirement in CI that a one-person engineering team cannot satisfy. Both are named in the gaps below rather than quietly dropped.
- We will share the full report, findings and remediation status, under NDA.
If something goes wrong.
- We notify an affected club within 72 hours of confirming a breach that touches its information, and notify members directly where the law requires it. This is a term of service, not a courtesy.
- Exceptions are grouped and alerted on, and a failed backup check emails the operators inline rather than through the queue it is checking.
- Report a vulnerability to security@bagdrop.ai. We will acknowledge within two business days, we will not pursue anyone acting in good faith, and we will credit you if you want the credit.
What we don't have yet
A trust page that lists only strengths tells a reviewer nothing they can act on. These are the things a club's IT reviewer will find anyway, put here so the conversation starts past them.
We have no report and no audit under way. What we offer instead: this page, the adversarial review under NDA, a completed security questionnaire, and contractual commitments on the controls that matter to you. If a certification is a hard requirement for your board, say so early — it is a question of when we start, not whether we would.
Our own adversarial review is the closest thing, and it was thorough enough to find three high-severity issues. An independent test is a reasonable thing to require in a contract, and we would welcome one your side commissions.
There is no native second factor for a staff password today. Staff who sign in with Google get Google's second factor, which is the practical answer for most clubs right now. Signing your staff and members in from your own identity provider is designed and next on the roadmap.
We do not publish an availability commitment, and there is no public status page. BagDrop runs on a single host by design at this stage; a club that needs a contractual availability figure should raise it, because the honest answer today is that we would be agreeing to something we have not yet measured over a long enough period.
Operator sessions expire daily. Member and staff sessions are deliberately long-lived, because the concierge and the staff console are installed on phones and carry notifications — an expiring session would silently stop those. A password reset, leaving the club, or removal of a staff assignment ends sessions at once. A member-initiated "sign out everywhere" is not built yet.
3 named operators, read-only, audited, on a database role that cannot write. Stated plainly here because you would discover it in diligence, and because the alternative — a dedicated instance with your own keys — is a real option we would rather discuss than have you assume away.
The managed database and the object storage holding your documents are both encrypted at rest by DigitalOcean, under DigitalOcean's keys. The backups we make ourselves — the queue replica and the nightly copy of your documents — are encrypted on our own host under keys we hold, but for the live stores we rely on the provider. That is the ordinary arrangement for managed infrastructure, and we apply it consistently rather than claiming a stronger guarantee for handbooks than for the conversations they inform. Worth knowing rather than discovering.
The only request a member's browser makes to a company that isn't our own infrastructure provider. Documents and photos are fetched straight from our object storage, which is DigitalOcean — the same company already running the server and the database, so it learns nothing from that request it could not already see. There is no analytics, no tracking pixel and no advertising script anywhere in BagDrop. Self-hosting the fonts is a small change if a club cares, and some do.
Questions we're asked
Grouped the way a review usually runs. If yours isn't here, security@bagdrop.ai answers it.
No, and no audit is under way. We will complete your security questionnaire, share our adversarial review under NDA, and make contractual commitments on specific controls. If certification is a board requirement, tell us early.
Not by a third party. A full adversarial review of the application on 4 September 2026 produced 34 findings — 3 high, 16 medium, 15 low. Every high was closed within three days. We will share the report and its current status.
Yes. Most of the answers are on this page, which is why it exists in this much detail — send it over and we will fill it in rather than pointing you back here.
Ask us for our current coverage and limits in writing, and we will provide a certificate. We are not going to state a figure on a page that may age.
No. Isolation is in the schema rather than in a filter: every member record hangs off a membership at one club, and there is no query shape that crosses. It is enforced by tests that fail the build, and the September review found no path around it from inside a club.
No. A person's list of clubs is unreachable from any club or staff context — a specific invariant, tested specifically, precisely because reciprocal and multi-club membership is sensitive in this market.
A single United States region: DigitalOcean, New York. Our subprocessors may process elsewhere under their own terms. There is no EU or UK region today.
In transit, TLS everywhere with HSTS. At rest, a managed Postgres cluster and object storage both encrypted by the provider, the server's own operational stores on a LUKS2 volume, offsite backup copies encrypted on the host before they leave it, and your vendor credentials encrypted at the column and never readable back.
No. We do not sell personal information, do not share it for cross-context behavioral advertising, and run no analytics, advertising or tracking scripts. The subprocessor table above is the complete list of who receives anything.
Members' and staff's access ends with the club's. Ask us for an export of your club's knowledge base and your members' conversation history and we will produce one; everything is then deleted on the schedule in the retention table, or sooner if you ask in writing. Audit records are retained for seven years with identities redacted.
No. There is no BagDrop model to train. The concierge runs on Anthropic's commercial API, whose terms exclude training on customer inputs and outputs. The only model on our own machine is a pre-trained embedding model doing inference.
Ask us for the current retention term on our account rather than taking a number from this page. Zero-retention terms exist and are available; if your review needs one, raise it and we will confirm the arrangement in writing.
It is instructed and structured to answer only from your published knowledge, to say what it is unsure of, and to hand off to your staff otherwise. We test that against the live model on 34 cases before shipping any change to its instructions, and no run has yet produced a wrong fee, a wrong rule, or a fact your corpus doesn't contain.
Everything the model reads — retrieved passages, past turns, documents, your newsletter — is wrapped in a per-turn random marker and labelled as reference material rather than instruction. Prompt-injection cases are one of the 7 arms in the behavioral suite, and none has ever failed.
Every tool reads through the asking member's own membership, so there is nothing to leak by construction. The one place members can learn anything about each other is the directory, which exists only if you turn it on, shows only what your own export marks visible, and audits every lookup including refusals.
Not today. BagDrop is in its information phase and writes nothing into any club system. When booking arrives it runs through a service account you provision and can revoke in one click, limited to a closed list of verbs, with per-turn call budgets. BagDrop never takes payment and holds no payment details.
A newsletter is trusted only as far as its DKIM or SPF alignment proves the sender. Anything applied from an unverified one is kept separate, marked unverified, and never presented as the club's own word until a staffer confirms it.
With a six-digit code or link emailed to the address on your roster: ten minutes, one use, five guesses, bound to the browser that requested it. Members hold no password with us. There is no self-service signup — if they aren't on your roster, they don't exist.
Not natively. Staff who use Continue with Google get Google's second factor. Your own identity provider is designed and next on the roadmap; a club that requires MFA today should put its staff on Google sign-in.
Signing in from your own member portal — your portal asserts, we verify — is designed and next up. Ask us for the timeline against your rollout date.
Remove their assignment from your team page and their staff sessions are revoked immediately, on every device. They are signed out, not merely un-listed.
Their standing follows your roster. On the next import a lapsed or resigned member drops to publicly visible knowledge only, and 12 months after the membership ends their conversations are removed by the nightly sweep.
3 named operators, on a read-only database role with a statement timeout, with every query recorded. That number is in our privacy policy and we update it when the team changes.
Yes, both, and without going through you. An "About you" page inside the concierge shows what we hold; a member can leave one club or delete their whole account, and erasure follows after a 7 days grace period. A suppression record means your next roster export won't resurrect them without their say-so.
BagDrop isn't directed to children under 13 and we don't knowingly collect their information. A club that enrolls a minor is responsible for the parental consent its own junior memberships and the law require. Tell us if a child's information reached us and we will delete it.
Our privacy policy grants access, correction, deletion, portability and non-discrimination rights to every member regardless of where they live, and we verify a request against the email on your roster. Data is processed in the United States. If you need a data processing addendum, ask and we will sign one.
Your club decides what is collected and why; we process it to run the concierge for you. Most of what we hold about a member came from your roster, which is why we may ask you to confirm a member's request before acting on it.
We don't publish one yet, and we would rather say that than quote a number we haven't measured over a meaningful period. Raise availability in the contract and we will talk about what we can genuinely stand behind.
Daily managed backups with point-in-time recovery; the job queue replicated every minute and its restore verified nightly by a job that writes a sentinel and reads it back out of the replica; uploads archived nightly, encrypted on the host, offsite.
A full database restore was rehearsed end to end on 8 September 2026: recovered to a timestamp six hours old rather than the newest backup, then checked for the vector extension, every migration rather than just the latest, and the row counts of the tables whose loss is the reason any of it exists. The rehearsal cluster was destroyed afterwards. We re-run it when the database's provisioning changes.
We do, for the backups we make ourselves: the queue replica is age-encrypted and the nightly copy of your documents is AES-256-GCM, both on our host before anything is uploaded, so those buckets hold ciphertext and nothing else. The stores themselves are the provider's — the managed database and the object storage holding uploads are encrypted at rest under DigitalOcean's keys, which is the same arrangement for your handbooks as for your members' conversations. The table above sets this out store by store, and a dedicated instance is the answer if you need the stronger guarantee.
Within 72 hours of confirming one that touches your information, to your named contact, in our terms of service rather than as a courtesy. Members are notified directly where the law requires it.
Write to security@bagdrop.ai. We acknowledge within two business days, we will not pursue anyone acting in good faith, and we credit reporters who want it.
Yes. Your own server, database, backups and keys, on our domain or yours, with no change to the software. Because the whole product is one deploy against one database, this is a commercial conversation rather than an engineering project.
Each property stays a full tenant with its own members, staff, knowledge and audit log. A group console reaches only the group's own properties, sees aggregates and never transcripts, and group staff get real, visible, revocable assignments at each property. A property can narrow a group's settings, never widen them. Ask for the design document.
What we'll send you
Available on request, most of it under a mutual NDA: the September adversarial review with its remediation status, a completed security questionnaire in your own format, our subprocessor list with change notice, a data processing addendum, our insurance certificate, and the group-of-properties design.
bagdrop.ai/terms
What changed, when
A trust page nobody updates is worse than none. This log is the proof that this one is maintained.