# Google Cloud IAM Helper: Agent Skills for Permission Errors and Policy Changes Google is giving coding agents a structured way to investigate cloud access, but the useful detail is where the workflow stops. By Paras Madan | 2026-10-26 Google Cloud introduced IAM Helper on October 26, a suite of Agent Skills and MCP tools for investigating permission errors, managing access policies and requesting temporary privileges. It connects coding agents to Google Cloud's existing access-control systems, with human approval separating diagnosis from changes to live permissions. For a team using agents to deploy applications, that distinction matters. A deployment blocked by a permission error needs an explanation and a narrowly defined fix. Giving the agent a broader role simply to make the error disappear can leave access behind long after the deployment finishes. ## What Google Cloud IAM Helper adds The [IAM Helper announcement](https://cloud.google.com/blog/products/identity-security/scale-agents-securely-with-iam-helper-agent-skills-and-mcp-tools/) brings together four workflows: policy management, access troubleshooting, policy simulation and Privileged Access Manager. Google names Gemini CLI, Gemini Cloud Assist, ADK, Claude Code and Cursor among the compatible agent environments. An Agent Skill packages instructions, supporting scripts and references for a task. MCP, the Model Context Protocol, provides a standard interface through which an agent can call tools. Here, the skills coordinate the work while Google's IAM services perform the underlying policy evaluation. This is a workflow layer around existing infrastructure, rather than a new model deciding who should have access. The distinction also explains why installing a skill does not give an assistant administrative authority over a project. ## How IAM Helper handles a permission error The [published Google skill definitions](https://github.com/google/skills/tree/main/skills/cloud) make the workflow more concrete than the launch headline. The troubleshooting skill separates a requester, such as a developer blocked during deployment, from a resolver with permission to investigate and change access. Suppose a deployment cannot use a Pub/Sub resource. The requester path can collect the error context, attempt permitted diagnosis, look at temporary-access options or produce a structured escalation. An administrator's path can investigate the relevant policies and identify an appropriate resolution. The important part is what happens when the investigation is inconclusive. The skill says to stop when access is unknown because required information is unavailable. It also stops if the troubleshooting identity itself receives a permission-denied response. If evaluation says access is already granted, it should not keep searching for additional roles to add. That is a useful constraint on an agent that might otherwise keep trying increasingly broad fixes. **An unknown result is a reason to escalate, not evidence that a larger role is needed.** ## Policy changes require a separate approval The policy-management skill distinguishes inspecting a policy from modifying it. For a change, it calls for an exact proposed command, a warning about the impact and propagation delay, and explicit confirmation before execution. It also requires a verification step after the approved change. These are instructions in the published workflow, not a substitute for IAM enforcement. Teams still need to control the identity and tools available to the agent. A model following a confirmation instruction and a backend refusing an unauthorized operation are different protections. For platform teams, the practical value is a more reviewable proposal. A reviewer should be able to see which identity needs which permission on which resource, instead of approving a vague instruction to fix the deployment. ## What the MCP connection requires The [Policy Troubleshooter MCP documentation](https://docs.cloud.google.com/policy-intelligence/docs/use-policy-troubleshooter-mcp) requires OAuth authentication and does not accept API keys. The underlying API must be enabled, and the caller needs permissions for both the MCP tool and the policies being inspected. Google lists Security Reviewer and MCP Tool User among the relevant roles, with additional roles for tasks such as inspecting deny policies. Equivalent permissions can also come from other predefined or custom roles. This is not a reason to grant every listed role to every agent; the required access depends on the investigation. Google recommends a separate identity for agents using MCP tools so their access can be controlled and monitored. The launch does not specify a standalone IAM Helper price or a single availability tier covering every underlying service. ## Why a 90-day simulation is not a guarantee IAM Helper also guides agents through policy simulation before applying changes. Google's [allow-policy simulator documentation](https://docs.cloud.google.com/policy-intelligence/docs/iam-simulator-overview) describes replaying recorded access from the preceding 90 days against current and proposed policies. That is useful evidence when reducing permissions, but its scope matters. The allow-policy simulator has unsupported resources and conditions, can return unknown results when information is missing, and fails if a simulation exceeds its limit of 5,000 access-log replays. Historical checks also cannot establish what an application will need tomorrow. A newly deployed feature or an infrequent maintenance job might not appear in the observed activity. **A successful simulation supports a policy decision; it does not prove that every future request will succeed.** ## Temporary access still starts with an entitlement The fourth workflow uses [Privileged Access Manager](https://docs.cloud.google.com/iam/docs/pam-overview). An administrator defines an entitlement: who is eligible, which roles can be granted, the maximum duration and any required approvals. An eligible requester can then request a time-limited grant. That can be a better fit for a maintenance task than a permanent role binding. It does not remove the need to define the entitlement, approve a request where required, or account for IAM propagation time. The useful thing to watch is whether IAM Helper makes access reviews more specific. Faster diagnosis helps, but the stronger outcome is a deployment unblocked with a clear explanation, a scoped change and no unnecessary standing permission left behind. I'm Paras. I work at the intersection of AI, engineering and distribution. I help technical founders turn complex product updates into clear launch stories that developers and founders understand and share. [Book a 30-minute call](https://cal.com/paras-madan/30min).