Google details IAM conditions to tighten cloud access

Google has outlined new ways to use Identity and Access Management conditions to tighten access controls in Google Cloud, with a focus on limiting broad permissions within projects.

The guidance centres on IAM conditions, which let administrators apply Common Expression Language rules to policy bindings when resource-level restrictions are not available. Google highlighted two main use cases: limiting the scope of administrative roles and restricting access to Model Context Protocol servers and tools.

Identity and Access Management is the system Google Cloud uses to control who can access cloud resources and what operations they can perform. Google framed the guidance around the Principle of Least Privilege, a security model that gives users and workloads only the minimum permissions needed to complete a task.

In many cloud deployments, teams rely on predefined roles, custom roles, and allow or deny policies set at the project, folder, or organisation level. But that structure can fall short when several workloads or teams share resources within the same project and a service does not support policy bindings on individual resources.

In those cases, IAM conditions can narrow access in ways that standard role assignment cannot. One example involved administrative privileges that are typically granted at project level and may allow far more actions than a workload needs.

Admin limits

Google used the Project IAM Admin role as an example. The role is narrower than the broader IAM Admin role because it limits administration to the project level, but it can still give a service account more authority than required.

Google described a scenario involving a builder service account that creates resources and deploys workloads. In that case, the workloads needed access only to BigQuery, Agent Platform APIs, and the ability to write logs and traces.

To limit the service account, the policy condition checks the roles being granted and permits only a defined list. Those allowed roles included AI Platform use, BigQuery job execution, BigQuery data viewing, Cloud Trace, and Cloud Logging.

The method relies on API attributes within the IAM condition expression. In practice, administrators can keep the broader project-level administrative role in place while constraining which grants can actually be made through that binding.

This matters because project-level roles often simplify operations, especially for deployment services and automation accounts, but they can also create openings for privilege escalation if left unrestricted. Limiting which roles may be granted reduces that risk without requiring a redesign of the project structure.

MCP access

The second example addressed access to MCP servers. Some cloud resources and services are exposed through MCP servers that provide Model Context Protocol endpoints, with access granted through the predefined MCP Tool User role.

Once an IAM policy is set, that role applies to all available MCP servers in a project. Google showed how an IAM condition can restrict the binding so a service account can reach only a specific service, such as BigQuery, by matching the resource.service attribute.

Google also described a more granular option at the tool level. In that setup, the condition uses an API attribute tied to the MCP tool name, allowing access only to named tools rather than the entire server set.

Its example limited a service account to two BigQuery MCP tools: one for SQL execution and one for read-only SQL execution. Google noted that when the policy is conditioned at the tool level, administrators do not need to validate the resource.service attribute separately.

The examples reflect a broader challenge for cloud operators as AI-related services and agent frameworks are folded into existing security models. Roles designed for convenience can expose broad access across a project, while newer interfaces such as MCP can group multiple services behind a single permission set.

Time controls

Google also highlighted time-based controls as another use of IAM conditions. A condition can permit access only during weekday business hours in a specified timezone by checking the request time and day of the week.

That allows administrators to restrict when an identity may use a role, helping reduce exposure for operational accounts or temporary access arrangements. The example allowed access from 9am to 5pm in the Europe/Berlin timezone from Monday to Friday.

At the same time, Google cautioned against using IAM conditions to control identity when a simpler principal list would do. It said identity checks through principal attributes can become an anti-pattern and recommended defining authorised actors through the IAM policy's principal list instead.

Google also pointed to IAM deny policies as another layer for organisations seeking tighter controls. That model lets administrators grant access with predefined allow roles and then remove unwanted permissions through deny rules to enforce least-privilege access more precisely.

Google said identity checks through principal attributes "can easily become an anti-pattern."