Security

What Nodrik can read, and what it cannot.

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

• Against your Google Cloud, Nodrik makes no write, update, create, delete or patch call.
• No IAM changes, no policy edits, no secret access.
• No deploys, rollbacks, scaling or traffic changes.
• No customer telemetry is copied out wholesale or indexed — what persists is the report and the redacted transcript behind it, deleted with your tenant.
• Tools you connect yourself are yours: Nodrik calls them and cannot verify what they do.

1 · What Nodrik can read

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

Optionally, per service you name, one more read-only role — a custom role defined in your project holding exactly the get and list permissions the tool behind it calls — so Nodrik can read a service's settings as well as its telemetry. Never granted with the four, never asked for in advance, deleted by the revoke script. For GKE it reads the GKE API and never connects to your cluster. The full list, verbs and all:optional configuration roles.

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

2 · What Nodrik cannot do

• It cannot write to your Google Cloud. Every call it makes against your project is a read: get, list, or query. There is no code path that mutates your infrastructure, and the roles above confer no write permission even if there were.
• It cannot verify a tool you connect yourself. If you point Nodrik at your own MCP server or endpoint, Nodrik calls it — and what that tool does is yours, not ours. We do not inspect it, we cannot tell whether it only reads, and we do not claim otherwise to the model. Nodrik prefers its own tools, reaching for yours only when the question needs them. Connect only tools you are content for Nodrik to call.
• It cannot act without an alert. Investigations start from an incident published by a Cloud Monitoring policy you own. Nodrik has no scheduler that reads your telemetry. The one scheduled call into your project is an hourly permission check (testIamPermissions and notificationChannels.list) on projects whose grant has not yet verified; it appears in the same audit log as everything else.
• It cannot expand its own access. The grant is IAM, held by you. Nothing in Nodrik 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

Nodrik is a reach-in product: telemetry is read at investigation time through your own APIs and used to answer one question. Your telemetry is never copied out wholesale or indexed. The transcript below is excerpts of what was read — each tool result capped at 4,000 characters — not a copy of the telemetry itself.

What we do store:

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

Every tool result is redacted before the model sees it, and the transcript again before it is written: private keys, API keys, bearer tokens, payment card numbers, email addresses (other than Google service-account identities) and IP addresses are replaced. Where each of the things above is held, service by service, is stated in the DPA(clause 7).

4 · It happens in your audit log

The grant is your action, performed by your administrator. Granting a role is an IAM policy change, so it lands in your project's Admin Activity audit log automatically — that log is always on and cannot be turned off.

The reads that follow are a different log. Every call the four viewer roles make —entries.list, timeSeries.list, groupStats.list,revisions.list, services.get — is a Data Accessaudit log entry, and Google leaves Data Access logging off by default for every service except BigQuery. Skip this step and the grant is logged; the reads it produces are not.

Turn it on once, for the services Nodrik uses, and it stays on:

1. In the Google Cloud console, open IAM & Admin → Audit Logs on the project you granted.
2. Select Cloud Logging, Cloud Monitoring,Cloud Run Admin and Error Reporting (add any configuration-role service you opted into — Cloud SQL, Memorystore, GKE, Compute Engine, or the load balancer).
3. For each, enable Admin Read and Data Read, then save.

From then on, every read is attributable and you can query it:

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

Before you turn it on, that same query returns only the grant itself and whatever else your project already logs — not Nodrik's reads. This is Google's default for every service on every Google Cloud project, not something particular to us; we would rather say so than let "attributable in your audit log" read as true before you have done anything.

Revoking is symmetrical: remove the role bindings — the four, and any optional configuration role — and Nodrik goes blind, immediately.

5 · Where things run

Nodrik runs on Google Cloud. Model inference runs on Vertex AI inside Google's boundary — your redacted telemetry excerpt is sent to Google's model endpoint as part of the investigation, and is not used to train models.

During an investigation Nodrik may also send a short search query to Google's documentation search API (the Developer Knowledge API, a Google Cloud API), and open one of the pages that search returned, to check an error message or a command against Google's current Google Cloud documentation — never the open web. After the report is written, the claims its suggested fix makes are checked the same way. The query is derived from the already-redacted investigation, and nothing is stored there.

Stated rather than buried: every model request goes to Vertex AI's global endpoint, so the telemetry excerpts in it may be processed outside the EEA. Nothing is stored there. Where each part of the product holds data, service by service, and the transfer terms that apply, are in the DPA (clause 7).

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 · Sub-processors

• Google Cloud — hosting, storage, sign-in, model inference and documentation search.
• Slack — delivery of the report to your workspace.
• GitHub — commit, diff and source reads, only if you install the app.
• Cloudflare — static hosting for this site and the console, the bot check on the signup form, and cookieless analytics on this site.
• Resend — transactional email from accounts@nodrik.dev.
• Stripe — payment processing.

The full list, with locations and notice terms, is in the data processing agreement. Questions: support@nodrik.dev.