What protects a club, and its members

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.
• Members, club staff and our own team each work on a separate origin, with separate sessions and separate gates. A session on one is not a session on another.

Enforced by tests that fail the build if broken, rather than by a policy someone has to remember

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, and whenever the owner disconnects it from their own page — so a mailbox someone loses control of cannot keep signing in as them.
• Your staff sign in the same way, and so do we. There is no staff password to guess, reuse, phish or relay — and nothing for anyone to hand a new colleague, because adding someone creates an account with no way into it but their own mailbox. Staff who prefer Google can use it, and bring Google's second factor with them.
• Rate limits on every sign-in endpoint, per requester and per address, so one inbox cannot be flooded from rotating machines. A staff sign-in link issued by a colleague for a member 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.

Signing in from your own member portal, and from your own identity provider, is in build now

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."

Your own documents are treated as untrusted input, like everything else the model reads

The concierge acts only where you have connected a system, and only within what you granted it.

• It reaches your systems through a service account you provision, scoped to what you decide it may do, revocable in one click, and never displayed back to anyone once stored. What it may do is a closed list of specific actions — there is no general-purpose access and nothing that executes arbitrary instructions.
• Every action is taken as the member who asked, through their own membership at your club — never an identity the model supplied. There is nothing for it to reach across by construction.
• Actions are budgeted per conversation turn, so a confused exchange cannot become a run of duplicate bookings, and each one is written to your audit trail with the member and the request behind it.
• Anything the concierge cannot do confidently it hands to your staff, and it never reports something as done that it has not confirmed in your system.

We measure the answering, not only the retrieval.

• Much of what keeps a member safe is written in the concierge's instructions rather than in code, so we test the instructions themselves — a suite of adversarial cases run against the live model, covering grounding, refusal, disclosure, prompt injection, restraint about acting, and how it handles what it has been told to remember. It runs before any change to those instructions ships.
• Across every run to date, none has produced a wrong fee, a wrong rule, or a fact your knowledge base does not contain. The failures we do record are the concierge deferring too little or overstating what it had done — both of which we treat as failures rather than relax.
• We would rather tell you what the suite covers than quote a percentage. A score without its test set behind it is a number, not an assurance.

A separate suite scores the newsletter reader before its behavior changes

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.

Ask us for the current retention term on our provider account

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 whose review requires stronger separation can be run on dedicated infrastructure — its own database, backups and keys. It is available on request, priced accordingly, and worth raising early so we can scope it against your timeline.

Your credentials cannot exist without a record of who at your club authorized them

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.

What each staff member can do is visible on one page of your console, and revocable there

Our own team can read member conversations. We would rather say so than imply otherwise.

• Access is limited to named people on our team, through a console that cannot write, on a database role that cannot write, with every query recorded. The other route in is being given a staff assignment at your club — which appears on your own team page, where you can remove it.
• There is no encryption on shared infrastructure that hides conversation content from us. Almost no vendor in this category can honestly claim otherwise; a club that needs that guarantee should ask about dedicated infrastructure with its own keys, and we will put the access policy and an audit review into the contract.

the honest answer, offered before it's asked for

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.

continuous integration on every push and pull request

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.

The invariants are the first thing a new engineer reads

We review our own systems adversarially, and fix what it finds before we call it done.

• The whole application is examined against an attacker's goals rather than a checklist — tenancy, authentication, what the model can be talked into, what an upload can carry, what a compromised session reaches. Last completed September 2026, and re-run when the architecture changes materially.
• Everything it surfaced was remediated as part of the review rather than logged for later. Where we decided against a change, that decision is written down with its reasoning, and the ones a club would care about are in the gaps below.
• We will walk your security team through the review and its outcomes 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.