Security

Bobbin reads your telemetry, transiently, using an identity you grant and can revoke. This page states precisely what that means. If anything here is vague, treat it as a bug and tell us.

1 · What Bobbin can read

One service account per customer, created in our project, granted these four roles by you on the projects you choose:

Role	Why it is needed
`roles/logging.viewer`	Read log entries around the incident — what the service actually said.
`roles/monitoring.viewer`	Read metric series — whether the symptom matches the timeline.
`roles/errorreporting.viewer`	Read error groups — what is failing and how often.
`roles/run.viewer`	Read Cloud Run revisions and their configuration — what changed in a deploy.

Optionally, a GitHub App you install with Contents and Metadata, read-only, on the repositories you select — so Bobbin can name the commit behind a deploy.

2 · What Bobbin cannot do

It cannot write anything. Every API call it makes is a read: get, list, or query. There is no code path that mutates customer infrastructure, and the roles above confer no write permission even if there were.
It cannot act without an alert. Investigations start from an incident published by a Cloud Monitoring policy you own. Bobbin has no scheduler pointed at your project and cannot poll you.
It cannot expand its own access. The grant is IAM, held by you. Nothing in Bobbin can request, escalate, or widen a permission.
It cannot apply a fix. Suggested remediations are text, always framed as suggestions to verify. Applying them is your decision and your command.

3 · What persists, and what does not

Bobbin is a reach-in product: telemetry is read at investigation time through your own APIs and used to answer one question. We do not ingest, index, or store your telemetry.

What we do store, in europe-west1:

The report Bobby posted, and the transcript of the investigation that produced it.
Your tenant record: which projects to watch, your Slack channel, your GitHub installation id.

Transcripts are redacted before they are written — email addresses and IP addresses found in log excerpts are replaced at persistence time.

4 · It happens in your audit log

The grant is your action, performed by your administrator, and it appears in your Cloud Audit Logs as such. Every subsequent read by Bobbin's service account is attributable to that identity. You do not have to take our word for what we read — you can query it:

gcloud logging read \
  'protoPayload.authenticationInfo.principalEmail="tenant-YOURID@bobbin-shard-0.iam.gserviceaccount.com"' \
  --project YOUR_PROJECT --freshness 30d

Revoking is symmetrical: remove the four role bindings and Bobbin goes blind, immediately.

5 · 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 boundary — your telemetry excerpt is sent to Google's model endpoint as part of the investigation, and is not used to train models.

6 · Read the exact grants before you run them

Onboarding is a documented set of gcloud commands. You can run the manual doc, the script, or the Terraform module — all three produce identical grants, and all three are readable before you run them. That is deliberate: the auditable script is the transparency artefact.

7 · Certifications, honestly

We are not SOC 2 certified. We run audit logging, least-privilege access, keyless CI, and PR-gated change control from day one, and we will certify when a customer's procurement process requires it. We would rather say that plainly than display a badge-shaped placeholder.

8 · Subprocessors

Google Cloud — hosting, storage, and model inference (europe-west1).
Slack — delivery of the report to your workspace.
GitHub — commit and diff reads, only if you install the app.

A DPA is available on request and will ship with the first paying customer. Questions:support@getbobbin.dev.