Security and trust
This page is the technical companion to getbobbin.dev/security — written for whoever has to sign off on granting Bobbin access, and for the assistant helping them check it.
The four roles
Section titled “The four roles”| Role | Reads | Verbs |
|---|---|---|
roles/logging.viewer | log entries — what the service actually said | entries.list |
roles/monitoring.viewer | metrics and alert policies — whether the symptom matches the timeline | timeSeries.list · alertPolicies.get |
roles/errorreporting.viewer | error groups — what is failing, and since when | groupStats.list |
roles/run.viewer | Cloud Run revisions and their configuration — what changed in a deploy | revisions.get · services.list |
The verbs matter more than the role names: they are the level at which “read-only” is either true or marketing. Full detail on how the roles are applied: Connect a Google Cloud project.
No write access, ever
Section titled “No write access, ever”- No write, update, create, delete or patch call exists in the codebase.
- No IAM changes, no policy edits, no secret access.
- No deploys, rollbacks, scaling or traffic changes.
- No customer telemetry is stored — reads are transient, at investigation time.
This is not a policy Bobbin follows; it is a property of the code. Bobbin’s own service accounts hold four viewer roles and nothing else — that list does not grow. Where a write is genuinely useful (the console’s grant wizard applying IAM bindings), it runs with the signed-in user’s own transient credentials, under their own authority, and the token is discarded once the grant is applied. Bobbin’s own identity never holds write access to your infrastructure, at any point.
Per-tenant identity
Section titled “Per-tenant identity”Every customer gets a dedicated service account, created for that workspace and used for nothing else. This is the confused-deputy defence: a bug, or a prompt injection carried in a log line, in one customer’s investigation is structurally unable to touch another customer’s project — there is no shared credential that spans a boundary for it to cross.
What persists, and what does not
Section titled “What persists, and what does not”Bobbin is a reach-in product: telemetry is read at investigation time,
through your own APIs, to answer one question, and then discarded. What
persists, in europe-west1:
- The investigation report Bobby posted, and the transcript that produced it — both redacted before they are written.
- Your workspace configuration: which projects to watch, your Slack channel, your GitHub installation id.
Your telemetry — logs, metrics, error groups, source code — is never copied out, never indexed, and never stored. Read the exact wording: the honest privacy claim.
Where things run
Section titled “Where things run”Bobbin runs on Google Cloud in europe-west1, and stores its data there.
Model inference runs on Vertex AI inside Google’s infrastructure boundary
— the telemetry excerpt used for an investigation is sent to Google’s
model endpoint as part of that investigation and is not used to train
models. Full detail on model routing and the residency claim it is built
on: the data processing agreement, clause 7.
Certifications, honestly
Section titled “Certifications, honestly”Bobbin is not SOC 2 certified. Audit logging, least-privilege access, keyless CI and PR-gated change control run from day one, and certification follows a customer whose procurement process requires it — stated plainly rather than with a badge that means nothing yet.
Sub-processors
Section titled “Sub-processors”The sub-processor list is maintained in exactly one place — the data processing agreement — with 30 days’ notice before any addition or replacement. It is not repeated here, so this page cannot quietly fall out of step with the list you are actually entitled to rely on.
Revoking access
Section titled “Revoking access”Revoking is symmetrical to granting: remove the four role bindings and Bobbin goes blind, immediately — see the removal instructions on whichever connection path you used. You do not have to run that yourself for your data to be deleted: Bobbin’s own side of the teardown — the service account, stored credentials, investigation history — runs on our schedule and does not wait for yours, within the 30-day bound the DPA sets.
Questions
Section titled “Questions”Anything at all, including “why do you need this role”: support@getbobbin.dev.