A Google Cloud blog post explains how to use IAM conditions to harden access management beyond what standard Allow and Deny policies provide. The post focuses on two detailed use cases: constraining administrative roles and controlling MCP Server access.

Standard IAM with Allow and Deny policies at the project, folder, or organization level is often insufficient when resources are shared between multiple workloads or teams. Binding IAM policies to specific resources helps, but it is not always possible. IAM conditions, expressed in Common Expression Language (CEL), provide surgical precision for these gaps.

Use Case 1 restricts the power of the Project IAM Admin role. The example grants this role to a builder service account but uses a condition to allow the account to grant only specific roles: BigQuery User, Agent Platform User, and the permissions to write logs and traces. The condition uses the api.getAttribute('iam.googleapis.com/modifiedGrantsByRole', []) function to limit which roles the grantee can assign. The post shows the equivalent gcloud CLI command and Terraform configuration.

Use Case 2 controls access to MCP servers, which expose cloud resources via the Model Context Protocol. The predefined MCP Tool User role grants access to all available MCP servers in a project. A condition can narrow this to a specific server, such as resource.service == 'bigquery.googleapis.com'. Access can be further scoped to specific MCP tools within that server, e.g., resource.name == 'bigquery.googleapis.com/mcp/tools/bqRead' || resource.name == 'bigquery.googleapis.com/mcp/tools/bqWrite'. When conditioning at the tool level, checking the resource.service attribute is unnecessary.

Beyond these examples, IAM conditions can control access based on request time, for example, allowing access only during daytime on weekdays using request.time and timezone functions. They can also control the identity of the actor using principal attributes, though the post recommends managing principals through the policy’s principal list instead of conditions to avoid anti-patterns.

The post concludes by noting that IAM Deny policies can complement Allow policy conditions for a deeper defense-in-depth strategy, linking to resources on supported permissions, principal identifiers, and troubleshooting.