Access & Billing

The “who can do what, who did what, and what does it cost?” tools. Reads run under your identity; the two IAM writes are approval-gated and — because access changes have the highest blast radius in GCP — deliberately narrow.

Resource Manager

• list_gcp_projects() — the projects your identity can access. Takes no project argument; it searches everything you’re granted, so it’s the natural first call.

IAM — policy

• get_project_iam_policy(project_id) — who holds which role on a project.
• grant_project_iam_role(member, role, project_id) — write. Adds one role binding for one principal (user:, serviceAccount:, group:, or domain:). It reads the live policy, modifies it, and writes it back; a no-op if the member already has the role.
• revoke_project_iam_role(member, role, project_id) — write. Removes that binding, dropping the role entirely when its last member goes.

Service accounts

• list_service_accounts(project_id) — the service accounts in a project.
• list_service_account_keys(email, project_id) — a service account’s keys with their age, flagging user-managed keys older than 90 days for rotation. (Creating and deleting service accounts are separate approval-gated writes.)

Who can reach what — Cloud Asset Inventory

• search_iam_policies(query, scope) — search IAM bindings across a project, folder, or org. Answers “who can reach this?” far faster than reading one policy at a time — for example query="policy:alice@corp.com".

Who did what — Cloud Audit Logs

• list_audit_logs(project_id, actor, hours=24, limit=10) — recent admin-activity entries, optionally filtered to a single actor. The “who changed this, and when?” answer, right in the thread.

Cloud Billing

• list_billing_accounts() — the billing accounts your identity can access, with open/closed state.
• get_project_billing_info(project_id), get_billing_costs(...), get_service_pricing(...) — the billing account behind a project, recent spend (needs a billing export table), and public list pricing.

The guardrail on IAM writes

An IAM grant is the highest-blast-radius approval enoki offers, so the plan you click binds an exact principal to an exact role on an exact project — recomputed at execution and void if any of it drifted. Two-approver sign-off (so one person can’t both propose and approve an owner grant) is the next control on the roadmap. Billing stays read-only for the same reason. See Guardrails.

Next: Secret Manager.