Review GCP IAM for Medical Websites with Claude Code

A clinic website can look simple while the access model behind it is messy. The inquiry form sends patient names, phone numbers, consultation details, and preferred appointment dates through a chain of Cloud Run, email, logs, CSV exports, and external vendors.

This article shows how a medical website team can use Claude Code to inventory GCP IAM without giving the agent patient data. The goal is not to make a flashy cloud architecture. The goal is to draw a boundary: what developers can inspect, what vendors can edit, what the clinic must approve, and what nobody should paste into an AI tool.

What This Article Covers

• Start from forms, emails, logs, and CSV exports before opening the IAM screen.

• Use Claude Code to draft tables for IAM roles, service accounts, logging paths, secrets, and review owners.

• Humans still decide patient data scope, clinic policy, vendor contracts, deletion requests, and publishing approval.

• Official references include Google Cloud IAM, service account guidance, Cloud Audit Logs, Data Access audit logs, Sensitive Data Protection, and Japanese privacy guidance for medical and care providers.

• Measure ROI with review time, broad roles removed, unknown service accounts, logging leaks, and vendor rework.

Where Medical Website Access Goes Wrong

The common failure is old access. A website vendor receives Owner access during launch. An ad agency receives a shared inbox. A retired staff account still has project access. A test service account keeps a broad role because nobody remembers why it was created.

The second failure is logging. A developer fixes a form bug and prints the entire request body. Suddenly the logs contain names, phone numbers, symptoms, free-text consultation notes, and appointment preferences. IAM can restrict the admin console, but logs and exports can become another route to the same data.

Use official documents as guardrails: Use IAM securely, service account best practices, Cloud Audit Logs, Data Access audit logs, Sensitive Data Protection, and medical and care privacy guidance.

Workflow: Work Backward from the Inquiry Form

Do not begin with role names. Begin with the patient-facing form, the email notification, the booking system, the CRM, Cloud Logging, and any CSV export. Draw where each field goes and who needs to see it.

For a first-visit form, the fields may include name, email, phone, requested treatment, free-text note, and preferred date. A web vendor may need to change the form markup and delivery code. That does not mean the vendor needs to read production consultation text.

Then list the Google Cloud resources: Cloud Run, Cloud Functions, Cloud Storage, Secret Manager, Cloud Logging, BigQuery, Pub/Sub, Cloud Build, domain settings, and notification credentials. Only after that map is visible should the team review IAM roles.

| Area | Inventory Fields | Human Review |

| --- | --- | --- |

| Inquiry form | fields, destination, confirmation page | whether the form asks for too much |

| Cloud Run or Functions | runtime service account, env vars | whether patient data reaches logs |

| Cloud Logging | viewers, retention, Data Access logs | who actually needs log access |

| Secret Manager | mail keys, API keys | whether secrets were shared in plain text |

| BigQuery or CSV | saved fields, viewers, exports | whether vendors can see patient data |

The practical rule is narrow first. Read-only before edit. Edit before administrator. Production after approval. Claude Code can help identify broad roles, but a human decides who must keep each access path.

What Claude Code Does and What Humans Decide

Claude Code is useful for evidence gathering. It can read IAM policy exports, service account lists, Cloud Run config, Terraform, YAML, README files, and logging code, then produce a table of who can touch which system.

Humans decide the boundary. Is a free-text note medical data? Can the ad agency see it? Should production logs include request bodies? Which vendor contract allows which access? Those are clinic and legal decisions, not agent decisions.

AI agents need the same boundary. Before giving Claude Code or Codex any Google Cloud credential, split read-only inventory, staging-only experiments, approval-gated changes, and production deployment. Recent Google Cloud IAM updates discuss agent access management and least privilege; medical websites should treat that as a design prompt, not a shortcut.

3 Use Cases

Use case 1: Review retired users and vendor IAM

• Input: gcloud IAM policy export, service account list, vendor scope, retired staff list.

• Output: member, role, purpose, patient-data touch point, review owner, and removal candidate.

• Human review: confirm whether a vendor still needs access, whether a contract covers it, and whether patient data is reachable.

Claude Code should not say delete this account. It should mark roles/owner, roles/editor, broad custom roles, and unknown service accounts as review candidates.

Use case 2: Find patient data in logging paths

• Input: form handler code, logger calls, Cloud Logging samples, notification email templates.

• Output: logged fields, mask candidates, remove candidates, and fields needed only for debugging.

• Human review: decide whether names, phone numbers, consultation text, symptoms, and preferred dates belong in logs.

This catches patterns like console.log(request.body), logger.info(payload), and raw JSON dumps. The fix is often to log event IDs, status, and masked fields instead.

Use case 3: Create a read-only path for AI agents

• Input: repository, project ID, resources to inspect, and data that must not be shared.

• Output: read-only tasks, staging-only tasks, approval-gated tasks, and prohibited tasks.

• Human review: check credentials, commands, output files, deletion targets, and deployment targets before execution.

The fastest agent setup is often the riskiest one. A medical website should separate inventory, test, change, and publish before giving an agent access.

Copy-Paste Prompt

Act as a GCP IAM inventory assistant for a medical website. The purpose is to keep patient data away from unnecessary staff, vendors, and AI agents.



Review IAM policy, service accounts, Cloud Run or Cloud Functions settings, Secret Manager references, logging statements, inquiry forms, booking forms, email notifications, and CSV exports.



Produce:

1. An access table with member, role, purpose, patient data touched, and reviewer.

2. A review list for owner/editor roles, unknown service accounts, retired users, and vendors.

3. A logging risk table for patient-data fields that should be masked or removed.

4. A three-column boundary: agent can inspect, human must approve, agent must not touch.

5. Do not run change commands. Produce a proposed diff first.



Do not paste real patient values. Do not make legal or medical conclusions. Mark approval steps clearly. Main CTA: /training/.

Working Check Code

const iamRows = [

  { member: "[email protected]", role: "roles/owner", purpose: "clinic owner", touchesPatientData: true, reviewer: "director" },

  { member: "[email protected]", role: "roles/editor", purpose: "LP edit", touchesPatientData: true, reviewer: "" },

  { member: "serviceAccount:[email protected]", role: "roles/secretmanager.secretAccessor", purpose: "form delivery", touchesPatientData: false, reviewer: "manager" }

];

const broadRoles = new Set(["roles/owner", "roles/editor"]);

const findings = iamRows.flatMap((row) => {

  const issues = [];

  if (broadRoles.has(row.role) && row.member !== "[email protected]") issues.push("review broad basic role");

  if (!row.purpose || row.purpose.length < 3) issues.push("purpose is missing");

  if (row.touchesPatientData && !row.reviewer) issues.push("patient data access has no reviewer");

  return issues.map((issue) => ({ member: row.member, role: row.role, issue }));

});

if (findings.length) { console.table(findings); process.exitCode = 1; } else { console.log("Medical site IAM draft passed."); }

Pitfall: The Agent Fixes Access by Expanding Access

The worst prompt is simple: look at GCP and fix it. That phrasing encourages the agent to request broad project access, read logs, inspect secrets, and pull production data because it wants to finish the task.

Fix the prompt by naming what the agent must not touch: patient names, phone numbers, consultation text, appointment details, production inboxes, and raw logs. Use column names, counts, and masked samples when possible.

Service accounts are another trap. They are non-human identities for workloads. A downloaded key on a laptop can be harder to trace than a retired employee account. Before adding a key, decide runtime identity, scope, logs, and reviewer.

FAQ

Q. Can Claude Code read a medical website repository? A. Usually the code and config are the right starting point. Do not paste real inquiry text until clinic policy and vendor handling are clear.

Q. Is removing roles/editor enough? A. No. Logs, secrets, CSV exports, notification emails, BigQuery datasets, and CI/CD can still expose data.

Q. Should Data Access audit logs be enabled? A. Decide by cost, retention, and audit needs. For medical websites, the team should at least review where read access needs evidence.

Q. Why is the CTA training? A. Permission, privacy, vendors, and publishing approval vary by clinic. This is not a generic download problem.

Talk to Us

ClaudeCodeLab training can help inventory a medical website’s forms, GCP IAM, logs, secrets, service accounts, and vendor boundaries. Start today by exporting IAM members and highlighting owner roles, editor roles, unknown service accounts, retired users, and vendors.

What I Actually Checked

This article checks frontmatter, official links, three use cases, input-output-human review labels, code fences, and the /training/ CTA. The JavaScript sample is syntactically valid and detects broad roles plus missing reviewers. Medical and legal decisions remain assigned to humans.