Gemini Can Recommend IAM Roles Through an API and MCP: Put Human Proof Around Policy Assist

Google Cloud now exposes Gemini-assisted IAM role suggestions through the console role picker, the Policy Assist REST API, and a Policy Assist remote MCP server. Separately, the IAM remote MCP server can inspect and manage custom roles and deny policies. That combination is useful, but it changes the failure mode: a recommendation can look precise while still ignoring inherited grants, conditions, deny rules, service dependencies, principal type, or the real resource boundary. A successful suggestion request proves only that the service returned candidates. It does not prove least privilege or authorize a production change.

The safe operating model is to treat Google Policy Assist IAM as candidate generation inside an existing access-control process. The team defines verifiable business actions, records the principal and resource hierarchy, compares exact permissions, tests both allowed and forbidden operations, obtains human approval, deploys through a controlled identity, observes the result, and keeps a reversal path. That discipline extends familiar cloud security least-privilege practices to AI-assisted access management without letting the assistant become the policy owner.

This playbook separates official product behavior from practitioner controls. It covers predefined and custom roles, console, API, and MCP paths, approval evidence, test principals, deny-policy interactions, rollout, rollback, and recertification. The core standard is simple: no role suggestion becomes an access decision until a named human can show what it permits, what it still forbids, where it applies, how the result was tested, and how the change will be reversed.

1. Define the Access Decision Before Asking for a Role

Start with an access decision, not a role name. A statement such as “give the application storage access” is too vague for a reviewer and too open-ended for Gemini. Translate the request into an action contract: one principal, named resources, required operations, explicitly forbidden operations, duration, owner, and the evidence that will count as success. This is the authorization equivalent of a test specification.

The prompt can ask for the “smallest,” “least privileged,” or “only exact permissions” design because the Gemini-assisted IAM role picker guidance says more specific least-privilege language produces more granular suggestions. That is a prompt-quality improvement, not a control. The authoritative requirement remains the action contract and the permission evidence reviewed against cloud security architecture principles.

Decision rule: A suggested role is an input to review. The approved decision is a signed record that binds a principal, role or permission set, resource scope, conditions, duration, tests, and rollback plan.

2. Map Principals, Resources, Actions, and Existing Policies

Before comparing candidates, build a four-part map. Record the principal in its canonical form, the full resource name or service-specific identifier, each required action, and every policy layer that can change effective access. The map should also show whether the principal is human or nonhuman, whether it can impersonate another service account, and whether a group or principal set sits between the requestor and the final identity.

Do not use the application’s friendly name as the boundary. An application may call Cloud Storage, Cloud KMS, Secret Manager, Artifact Registry, and a service account in another project. The access design must follow those calls. Missing a transitive dependency creates false denial; broadening the role to compensate creates over-permission.

2.1 Record the Resource Hierarchy and Inherited Bindings

Google Cloud allow policies are hierarchical. A principal can receive a role at the organization, folder, project, or service-resource level, and grants at a parent flow to descendants. The IAM allow-policy model also means that a resource’s local policy is not the whole access picture. Inventory direct and inherited bindings before adding another one.

For each candidate, create a scope line such as: principal, role, attachment point, descendants affected, and condition. If a bucket-level grant satisfies the need, a project-level grant is not equivalent merely because both make the test succeed. Review the effective policy in the console or use a method that exposes inherited access; a direct get-policy response for one resource should not be treated as an effective-policy report.

Scope acceptance gate: The reviewer can trace every required permission to the lowest usable attachment point and can explain every inherited grant that affects the test principal. Unexplained inherited access is a stop condition, not a reason to proceed with another binding.

2.2 Identify Conditions, Deny Policies, and Service Agents

Permissions listed in a role are only one input to effective access. A condition can prevent a binding from applying; a deny policy can override an allow; a principal access boundary can limit reachable resources; and service-specific controls can reject a request after IAM evaluation. The IAM deny-policy overview is especially important because a matching deny takes precedence over a role grant and is inherited from organization, folder, and project attachment points.

Record each condition expression, its attributes, its intended time or resource boundary, and how it will be evaluated during testing. For deny policies, record the attachment point, denied principals, denied permissions, exceptions, tag conditions, and policy etag. Do not assume that a denied permission uses the same notation as an allow-role permission; the deny API uses fully qualified permission names.

Treat Google-managed service agents as a separate principal class. Their roles support a service’s internal operation and can change as the service evolves. Do not copy service-agent roles to an application identity, replace them casually, or use the service agent as the test principal. A recommendation that overlooks a required service agent is incomplete; a recommendation that grants a service-agent role to the workload should be challenged.

3. Understand Console, API, and MCP Recommendation Paths

The recommendation path determines what the assistant can see and what it can change. As of September 14, 2026, the console role picker suggests predefined roles for an individual principal. The page also exposes a Preview REST path through Policy Assist and points external clients to a Preview Policy Assist MCP server. By contrast, the IAM remote MCP server is a separate administrative surface for custom roles and deny policies.

There is a documentation timing difference worth naming. The role-picker page was last updated July 29, 2026, while the IAM release notes announced programmatic Policy Assist role suggestions on September 9, 2026, and the IAM MCP documentation was updated on September 10. Use the latest release notes and current API or MCP reference to decide launch status and tool availability. Use the role-picker page for console behavior, required permissions, prompting guidance, and the warning to validate Gemini output.

The Policy Assist role recommendation method can return predefined or custom candidate roles and grantable scopes, but a returned scope is not an approval to grant there. The Policy Assist remote MCP guide requires MCP Tool User and IAM Viewer capabilities for its documented recommendation path. The IAM remote MCP guide requires additional role-administration or deny-administration permissions when its management tools are used. Keep these identities distinct even if one human operates both workflows.

4. Separate Read-Only Assistance From IAM Write Authority

A recommendation workflow and an IAM administration workflow should not share credentials. The first needs enough access to describe available roles and return suggestions. The second can alter a custom role or deny policy, and a separate deployment mechanism may alter an allow-policy binding. Combining them lets a prompt, compromised client, or mistaken tool selection turn advice into an authorization change.

Use three identities where possible: a recommendation identity, a change executor, and a test principal. The recommendation identity cannot write IAM state. The executor is activated only for an approved change. The test principal represents the workload but owns no production data and has no unrelated inherited grants. This separation makes logs interpretable and rollback targeted.

4.1 Build a Read-Only Policy Assist Profile

The read-only profile should be a dedicated nonhuman identity for the approved AI client. Grant only the Policy Assist MCP prerequisites required for role suggestions on the designated project. Do not grant Project IAM Admin, Role Administrator, Deny Admin, service account impersonation rights, or generic project Editor access merely to make setup easier.

Google recommends a separate identity for agents that use MCP tools. Apply that recommendation literally. Also note that tools/list does not require authentication on the documented Policy Assist server. Tool discovery is not proof that the caller can invoke a tool, and it is not an authorization inventory. Evaluate the actual call under the identity and policies that will be used.

4.2 Gate Role and Binding Changes Separately

The write profile is a privileged deployment identity, not the recommendation agent with more permissions. Activate it through a separately approved workflow using short-lived credentials. Google’s short-lived service account credential guidance supports impersonation patterns that avoid distributing persistent keys. Grant the caller only the token-creation capability needed for the approved target identity, and log the impersonation chain.

For MCP administration, enforce both mcp.tools.call and the underlying IAM permission. The MCP IAM control model can evaluate principal, service, tool name, OAuth client, and whether a tool is read-only. Use those attributes to block non-read-only tools for the recommendation identity. Keep the permission to alter allow-policy bindings in a separate deployment path because the current IAM remote MCP documentation focuses on custom roles and deny policies, not a universal binding-management interface.

This split also clarifies cybersecurity and DevSecOps ownership: security owns authorization standards and exception acceptance; the platform team executes an approved change; the application owner validates the business action; and audit or governance verifies the evidence. No one should use an AI session as a substitute for those accountable roles.

5. Compare Suggested Predefined Roles by Exact Permissions

Consider an invoice-normalizer service account that uses one dedicated Cloud Storage bucket. It needs exactly three business actions: list objects awaiting processing, read an existing object, and create a new uniquely named normalized object. It must not delete, overwrite, move, restore, update metadata, manage folders, or change bucket IAM. The test account has no inherited Storage role.

Gemini might suggest Storage Object User because it covers all three operations. A narrower predefined design combines Storage Object Viewer and Storage Object Creator. The current Cloud Storage role definitions show why the names alone are not enough: both designs satisfy the required operations, but they carry different adjacent permissions.

Candidate B is materially narrower because it excludes object deletion and update. The Cloud Storage permission reference states that replacing an existing object requires both create and delete, so a principal with Creator but without delete should fail an overwrite test. Candidate B is still not an exact three-permission role: it includes supporting project, folder, managed-folder, multipart, and context permissions. Those extras must be listed in the review, not hidden behind the phrase “least privilege.”

Worked-example decision: Reject Object User because its delete, update, move, and restore capabilities violate the negative boundary. Accept Viewer plus Creator only if the owner and security reviewer explicitly accept every auxiliary permission at bucket scope. If policy requires only the three business permissions, evaluate a custom role instead.

Version the comparison evidence. Save the live role definitions, retrieval time, candidate response, permission-set digest, and reviewer disposition with the ticket. Predefined roles are maintained by Google and can gain or lose permissions as products change. The approved object is therefore not just the role name; it is the role name at a recorded decision point, plus a rule for detecting and reviewing later drift. This evidence also prevents a future reviewer from assuming that today’s definition is identical to the one that was originally accepted.

6. Decide When a Custom Role Is Justified

Google recommends predefined roles when they fit, because Google maintains them as services evolve. A custom role is justified when every available predefined design contains a material permission that the risk owner will not accept, or when the required permission set spans a combination that predefined roles cannot express safely. It is not justified merely because a model generated a plausible title.

For the invoice-normalizer example, the candidate custom role would begin with the three permissions below. Before creation, confirm each permission’s custom-role support level and confirm that the project or organization level where the role will live can use it.

storage.objects.get
storage.objects.list
storage.objects.create

The role-type selection guidance describes the tradeoff: custom roles can tighten access, but the customer owns maintenance. The custom-role support reference classifies permissions as supported, testing, or not supported. Do not put a testing permission into a production role merely to satisfy a deadline. The custom-role creation guidance also requires lifecycle, stage, update, and etag discipline.

Assign a named role owner, baseline the permission list, subscribe to service-change review, and test after any update. A custom role can become too narrow as an application changes, or too broad when an owner adds permissions to fix an outage. Stop the workflow if the role has no owner, contains wildcard-style thinking, includes unsupported permissions, or lacks a recertification date.

7. Test Positive and Negative Access With a Test Principal

Testing must answer two different questions. Policy Troubleshooter predicts whether IAM policy allows one principal to use one permission on one resource. A controlled test principal proves whether the actual client can complete or fail an operation in the target environment. Neither result replaces the other. This is zero-trust verification applied to authorization: verify the requested action and the boundary around it.

Run one Policy Troubleshooter request for each positive and negative permission. Use the full resource name and the exact test principal. The documented command shape is:

gcloud policy-intelligence troubleshoot-policy iam \
  //storage.googleapis.com/projects/_/buckets/BUCKET_NAME \
  --principal-email=iam-role-test@PROJECT_ID.iam.gserviceaccount.com \
  --permission=storage.objects.get

The Policy Troubleshooter documentation evaluates allow policies, deny policies, and principal access boundary policies that the caller can view. If the operator lacks access to an applicable policy or custom role, the result can be unknown or incomplete. It also does not account for Cloud Storage ACL grants and does not diagnose VPC Service Controls. For this example, use a dedicated bucket with uniform bucket-level access, or review ACL and perimeter controls separately.

Use nonproduction data and a test identity that has no group membership, inherited broad role, user-managed key, or impersonation path unrelated to the change. Capture the token issuer, client command or test code version, request timestamp, object names, response codes, and post-test state. A positive API response proves only that one operation succeeded; it does not prove the application’s complete business workflow or the absence of another access path.

Failure injection: In an isolated test project, first confirm that the target permission is supported in deny policies, then add a temporary deny rule for the test principal’s object-create permission at the project attachment point. Confirm that Policy Troubleshooter changes from allowed to denied and that the upload fails. Remove the injected rule from the test policy, wait for propagation, rerun both checks, and confirm recovery. Do not delete a production deny policy for this exercise; deny-policy deletion is permanent.

Measurable acceptance gate: Three of three required permissions are allowed in both modeled and real tests; three of three forbidden operations are denied; every extra permission has a recorded disposition; no test returns Unknown; and the owner and IAM reviewer sign the same evidence package. Any forbidden success, unexplained inheritance, incomplete policy visibility, or failed recovery is a stop condition.

8. Review AI Output for Missing Context and Over-Permission

Review the recommendation as an assertion that can be falsified. Extract each role name, permission claim, grantable scope, and reasoning statement. Resolve the role against the live IAM roles and permissions index, not a copied list or model explanation. Then compare the resulting permission set with the action contract and scope map.

Flag three classes of error: a missing required permission, an extra permission outside the negative boundary, and a correct permission proposed at the wrong resource level. The reviewer should also verify that the role still exists, is appropriate for the principal type, and has not changed since an earlier ticket.

8.1 Validate Scope, Conditions, and Cross-Service Dependencies

A role can be correct for an API call and still be wrong for the system. Trace the application’s real call path: runtime identity, service account attachment, token exchange, storage or database access, encryption key use, secrets, build and deployment services, logging, and any cross-project resource. Each dependency gets its own principal, resource, permission, and negative test.

Conditions require the same rigor. Confirm which attributes exist for the target resource and request, how time zones are interpreted, and what happens when an attribute is absent. A condition that makes the positive test pass once can still block a scheduled workload later. Conversely, a broad parent grant can make an incorrect condition appear harmless.

Do not “fix” a missing dependency by escalating to a broad service Admin role. Return to the action map, add the missing call and permission, and rerun the comparison. When a Google-managed service agent performs part of the workflow, test the application identity and inspect the service agent’s existing grant separately.

8.2 Challenge the Recommendation With Counterexamples

Counterexamples expose the boundary that a happy-path prompt hides. Challenge at least the following cases:

•         Run the same operation against a second bucket, another project, or a sibling folder.

•        Address an object outside the intended prefix or repeat the call after the temporary period.

•         Attempt delete, overwrite, move, restore, metadata update, and policy modification operations.

•         Attempt to impersonate another service account, create a key, or reach a resource through a different identity path.

•         Attempt to disable, edit, or bypass the control that produced the approval evidence.

An AI assistant may help enumerate counterexamples, but the reviewer chooses which ones matter and interprets the result. Do not let the same model produce the role, select its own negative tests, and declare them sufficient. Independent human review is valuable precisely because the recommendation and its self-critique can share the same missing context.

9. Approve and Deploy Changes Through a Controlled Workflow

Move from recommendation to production through an evidence-bearing change record. The record should be reproducible without reopening the AI conversation: action contract, prompt, response, exact permission diff, resource-scope map, existing-policy snapshot, test matrix, result artifacts, approvers, deployment identity, observation plan, and rollback instructions. This is the IAM-specific application of DevSecOps governance practices.

Use rollout rings even for a small binding: isolated test resource, nonproduction environment, production canary principal or narrow resource, then full approved scope. Preserve the pre-change allow policy and relevant etags. The guidance for managing access on service resources emphasizes reading the current policy, modifying it, and writing it back without discarding concurrent changes. Never replace a whole policy from a stale local copy.

Match the evidence to the deployment path. For a console change, retain the final grant preview and the resulting policy etag or audit event. For an API, infrastructure-as-code, or MCP-assisted change, retain the reviewed request, tool or command identity, operation result, and a post-write readback. A green execution status means the write was accepted; only the readback and authorization tests show that the intended state became effective without altering unrelated policy.

Approval gate: The change executor verifies that the ticket’s principal, role, attachment point, condition, and expiry exactly match the deployment payload. A mismatch returns the ticket to design. Approval text such as “looks good” without those identifiers is not authorization.

10. Observe Authorization Failures and Unexpected Access

Observation starts immediately after deployment and lasts long enough to cover normal workload cycles. Watch both sides of the boundary: expected authorization failures, unexpected successful access, application errors, latency or retry changes, and operations that bypass the path used in testing. A quiet error dashboard is not proof that least privilege is correct; the application may not have exercised the protected path.

Enable the audit evidence required before rollout. Google Cloud MCP audit logging guidance records service-specific MCP activity, while Data Access audit-log configuration may need explicit enablement and can add logging cost. For every MCP tool invocation, retain caller, project, service, tool name, read-only annotation, arguments or a safely redacted digest, authorization result, operation ID, response status, client or OAuth identity, and linked change ticket.

Define rollback triggers in advance: a forbidden operation succeeds, the workload reaches another resource, a required operation fails beyond the propagation window, an unknown principal invokes a tool, a non-read-only tool is called by the recommendation identity, or logs are unavailable. Pause further rollout on the first trigger. Investigate policy propagation and service controls, but do not widen the role as the first response.

11. Roll Back Bindings, Roles, and Agent Credentials

Rollback must be prepared before the write identity is activated. Store the exact pre-change policy or role definition, etag, attachment point, principal, condition, and credential state. The recovery objective is not merely to make the application work; it is to restore the last approved authorization state and then verify both positive and negative access again.

The deny-policy management guidance notes that policy changes usually propagate within minutes but can take longer. Treat the propagation period as an uncertain state: do not declare recovery after one successful request. Repeat the full matrix after the expected window and record the effective policy result.

Maintain a break-glass path controlled by people who are not dependent on the failed identity or the modified policy. Require two-person authorization, time-bound activation, complete logging, and post-event review. If a change locks out the normal administrators, the recovery team should restore the prior state, not improvise a broader permanent grant under incident pressure.

12. Govern MCP Sessions, Logs, and Prompt Injection Risk

An MCP client expands the trust boundary beyond the Google Cloud API. Prompts, retrieved documents, tool descriptions, saved conversations, and model memory can influence which tool is selected and which arguments are sent. The operating model should therefore treat AI agent context and memory as potentially persistent input to an authorization workflow, not as harmless chat history.

Keep approval data outside the model session in a signed change system. The agent may read a ticket identifier and approved parameters, but it should not infer approval from phrases in a document, issue, email, or retrieved web page. Ignore any instruction embedded in untrusted content that asks the client to reveal credentials, broaden scope, select a write tool, disable a deny policy, or bypass human review.

The read-write MCP prevention control demonstrates an IAM deny condition based on a tool’s read-only attribute and warns that tool discovery can still list write-capable tools. Use defense in depth: principal separation, tool and service allowlists, OAuth-client restrictions where supported, short-lived credentials, network and client controls, and audit alerts. Tool annotations are useful signals, but the underlying IAM permissions and human approval remain authoritative.

Log every invocation, including failed and denied calls. A missing log is itself an incident condition because the team cannot reconstruct what the agent attempted. Rotate or revoke the write profile after the approved window, and invalidate any session that outlives a scope change, role update, approval withdrawal, or suspected prompt-injection event.

13. Recertify Roles and Remove Temporary Access

Rollback handles a change that is wrong now. Recertification asks whether an access decision that was once correct is still justified. Set a review cadence based on privilege and data sensitivity, with shorter intervals for custom roles, agent identities, write-capable MCP access, cross-project grants, and exceptions. Temporary access should have an enforceable expiry where the product supports it and a removal task that does not rely on memory.

Usage data can support review, but nonuse is not automatically proof that a permission is unnecessary, and use is not proof that it is appropriate. Confirm business need with the resource owner, compare live permissions and hierarchy with the approved record, rerun selected positive and negative tests, and remove stale identities, temporary conditions, and unused write profiles in a controlled order.

Close the loop by recording what was removed, when propagation completed, and whether any workload failed. A recertification that merely renews the previous ticket without a live role diff and effective-access check is administrative repetition, not governance.

14. Establish Acceptance Evidence and Human Accountability

Production acceptance should be a binary evidence decision, not a confidence score from the assistant. The change passes only when the package below is complete and internally consistent. If one item is missing, the approver either rejects the change or records a time-bound exception with a named risk owner and compensating control.

Name the people behind the controls. The application owner attests that the three business actions are complete. The IAM or security reviewer attests that the permission and scope analysis is correct. The platform executor attests that only the approved payload was deployed. The risk owner accepts any residual permission. The observer confirms post-change evidence. An agent can prepare artifacts, but it cannot hold these accountabilities.

Teams building these foundations may find the Refonte Learning Cloud Security Engineer Program relevant. The published program runs for three months at approximately 10 to 12 hours per week and covers transferable areas including identity and access management, encryption, threat detection, incident response, compliance, monitoring, and zero-trust security. That connection is to the underlying security disciplines, not a claim that the program teaches Policy Assist, Gemini role recommendations, or the IAM MCP server.

The acceptance standard is deliberately stricter than “Gemini suggested a role” or “the API returned success.” A defensible Google Cloud IAM change has a bounded business purpose, an exact principal and resource map, a permission-level comparison, modeled and real positive tests, negative tests that remain denied, independent approval, observable deployment, and a rehearsed reversal path. Console convenience, API reasoning, and MCP automation can shorten discovery, but none of them receives authority to decide who should access production resources.

Keep recommendation, administration, and testing identities separate. Stop when effective policy is unknown, a forbidden action succeeds, logs are unavailable, or rollback evidence is missing. Recover by restoring the last approved state and repeating the full matrix, not by granting a broader role to make an error disappear. Recertify later because roles, applications, principals, and organizational boundaries change. Human proof is the durable control: it turns an AI-generated candidate into a reviewable, reversible, and auditable access decision.