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 stored — reads are transient, at investigation time.
• 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, never indexed, and never stored.

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, and it appears in your Cloud Audit Logs as such. Every subsequent read by Nodrik'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@tg-shard-0.iam.gserviceaccount.com"' \
  --project YOUR_PROJECT --freshness 30d

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.