AutoGineer
Generated banner for Iam Helper For Policy Management
Generated logo for Iam Helper For Policy Management

Iam Helper For Policy Management

GoogleOfficialPublished by Google

  • Skill
  • Tool integration
  • Security
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Streamlines the creation, modification, and management of IAM allow policies (v1) and deny policies (v2). Manages access control across Resource Manager resources (Organization, Folder, Project) and individual resources. Use when creating, updating, listing, or deleting IAM allow policies or deny policies. Don't use for access denial troubleshooting (use iam-helper-for-troubleshooting), temporary privileged access (use iam-helper-for-privileged-access-management), configuring VPC Service Controls, or managing network firewall rules.
— the description by Google

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a standardized workflow for managing Google Cloud IAM v1 allow policies and v2 deny policies. It enforces a strict Plan & Confirm protocol for all mutating operations to prevent accidental security misconfigurations. The skill handles the lifecycle of policies across the Resource Manager hierarchy, including organizations, folders, and projects, while ensuring all commands are properly attributed for auditability.

What it does

  • Lists and inspects existing IAM allow and deny policies.
  • Generates gcloud commands for adding, updating, or removing policy bindings.
  • Enforces a mandatory confirmation step before executing any policy changes.
  • Verifies the state of policies post-execution to ensure accuracy.
  • Applies required usage attribution tags to all CLI and API interactions.
  • Prevents the assignment of dangerous blanket roles like allUsers or allAuthenticatedUsers.

When to use it

  • When you need to grant or revoke access for users, service accounts, or groups.
  • When creating organization-level guardrails using IAM v2 deny policies.
  • When auditing current IAM policy configurations across your resource hierarchy.
  • When you need to perform bulk updates to IAM policies via JSON or YAML files.

Advantages

  • Reduces risk of accidental access changes through mandatory confirmation.
  • Ensures consistent and auditable command execution with automated attribution.
  • Promotes least-privilege security by blocking blanket public access requests.
  • Simplifies complex policy management across different resource levels.

Usage examples

“List all IAM allow policies for project my-project-123.”
The agent executes the appropriate gcloud command with attribution and displays the current policy configuration.
“Add user [email removed] as a viewer to project my-project-123.”
The agent generates the command, warns about the impact, and waits for your explicit approval before applying the change.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/google/iam-helper-for-policy-management/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip iam-helper-for-policy-management.zip -d .agents/skills

Documentation by Google

IAM Helper for Policy Management

Orchestrates the lifecycle and management of IAM allow and deny policies across IAM v1 (allow policies) and IAM v2 (deny policies).

Usage Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read and follow the instructions in Usage Attribution.

Core Concepts & Paradigms

IAM operates across two policy paradigms:

  1. IAM v1 (Allow Policies): Grants roles to principals (users, service accounts, groups, domains) on specific resources. Supports Resource Manager resources (organizations, folders, projects) as well as individual resources across supported Google Cloud services.

  2. IAM v2 (Deny Policies): Sets explicit organization-, folder-, or project-level guardrails that prevent specified principals from using designated permissions, regardless of any allow policies granted. Evaluated before allow policies.

Workflow & Decision Tree

When receiving a policy management request, determine whether the operation is Read-Only or Mutating, and whether it targets IAM v1 (Allow Policies) or IAM v2 (Deny Policies):

1. Read-Only Operations (Autonomous Execution)

Read-only actions include the following:

  • IAM v1 Allow Policies: get-iam-policy on project/folder/organization, or gcloud iam list-testable-permissions //cloudresourcemanager.googleapis.com/projects/PROJECT_ID.

  • IAM v2 Deny Policies: gcloud iam policies list or gcloud iam policies get with --attachment-point and --kind=denypolicies.

For read-only actions, execute the command autonomously to inspect state, and present the query results clearly to the user.

2. Mutating Operations (Plan & Confirm Protocol)

Mutating operations include the following:

  • IAM v1 Allow Policies: add-iam-policy-binding, remove-iam-policy-binding, or set-iam-policy across project, folder, organization, or resource levels (see references/v1-allow-policies.md).

  • IAM v2 Deny Policies: create, update, or delete deny policies on attachment points (cloudresourcemanager.googleapis.com/projects/PROJECT_ID, cloudresourcemanager.googleapis.com/folders/FOLDER_ID, or cloudresourcemanager.googleapis.com/organizations/ORG_ID) using YAML/JSON policy files (see references/v2-deny-policies.md).

For mutating operations, follow the Plan & Confirm Protocol below. DO NOT execute mutating commands autonomously without prior user approval.

Execution & Safety Protocol

  • Plan and Confirm (No Autonomous Mutation): Mutating allow and deny policy changes modify live security perimeters and access controls. You MUST NOT execute mutating gcloud commands directly via tool calls without explicit prior confirmation from the user. When asked to apply a mutating change, do the following:

    1. Formulate the Command: Generate the exact, fully constructed gcloud command (including all parameters such as --member, --role, --attachment-point, --kind=denypolicies, and --policy-file).

    2. Warn of Impact & Propagation: Issue a general warning that the change could impact access in a live environment and takes time to propagate across Google Cloud global infrastructure.

    3. Request User Confirmation: Prompt the user for approval before applying the changes to the live environment.

  • Post-Execution Verification: After the user approves and the mutating policy change is executed, run the corresponding verification command (see references/v1-allow-policies.md and references/v2-deny-policies.md for exact verification steps) to verify that the active state matches expectations before reporting completion.

  • Security Guardrail (Public & Blanket Access Refusal): Never grant allUsers or allAuthenticatedUsers basic roles (roles/owner, roles/editor, roles/viewer, roles/admin, roles/writer, and roles/reader) or broad permissions. Explicitly refuse blanket public access requests, explain the severe security risks of public project ownership/access, and propose scoped, least-privileged role bindings for specific authenticated identities instead.

Supporting Links

Files

references/v1-allow-policies.md

IAM v1 Allow Policies

This reference guide details how to manage IAM v1 allow policies across Resource Manager hierarchy levels (Organization, Folder, Project) and individual resources using gcloud CLI.

Table of Contents

  • 1. Overview

  • 2. Managing Allow Policies via gcloud CLI

  • 3. Verification Plan

1. Overview

IAM v1 allow policies define who (principals) has what access (roles) on which Google Cloud resources.

Principals (Who Is Granted Access)

The following are examples of principal types that are supported in allow policies (see Principal Identifiers Overview for a comprehensive list):

  • Users: Google accounts (e.g., user:[email protected]).

  • Service Accounts: Application identities (e.g., serviceAccount:my-sa@PROJECT_ID.iam.gserviceaccount.com).

  • Google Groups: Groups of users (e.g., group:[email protected]).

  • Domains: Google Workspace or Cloud Identity domains (e.g., domain:example.com).

  • Special Identifiers: allUsers (public) and allAuthenticatedUsers (authenticated Google accounts).

Resources (Where Policies Apply)

  • Resource Manager Resources: Applies at the organization, folder, and project resource levels. Permissions inherit down the resource hierarchy.

  • Service-specific Resources: Applies to individual resources across supported services. These allow policies complement policies inherited from ancestor resources (projects, folders, and organizations).

Roles (What Is Granted)

  • Predefined Roles: Managed by Google Cloud, providing curated collections of permissions for common use cases.

  • Custom Roles: User-defined collections of granular permissions tailored to specific least-privilege requirements.

2. Managing Allow Policies via gcloud CLI

A. Resource Manager Resources
1. Project Level
# Add Policy Binding
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:[email protected]" \
    --role="roles/viewer"

# Remove Policy Binding
gcloud projects remove-iam-policy-binding PROJECT_ID \
    --member="user:[email protected]" \
    --role="roles/viewer"

# Set Policy (bulk replacement)
gcloud projects set-iam-policy PROJECT_ID policy.json

# Get Policy
gcloud projects get-iam-policy PROJECT_ID --format=json

# List Testable Permissions for Resource
gcloud iam list-testable-permissions //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
2. Folder Level
# Add Policy Binding
gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \
    --member="serviceAccount:my-sa@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/resourcemanager.folderViewer"

# Set Policy (bulk replacement)
gcloud resource-manager folders set-iam-policy FOLDER_ID policy.json

# Get Policy
gcloud resource-manager folders get-iam-policy FOLDER_ID --format=yaml

# Remove Policy Binding
gcloud resource-manager folders remove-iam-policy-binding FOLDER_ID \
    --member="serviceAccount:my-sa@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/resourcemanager.folderViewer"
3. Organization Level
# Add Policy Binding
gcloud organizations add-iam-policy-binding ORG_ID \
    --member="group:[email protected]" \
    --role="roles/iam.securityReviewer"

# Set Policy (bulk replacement)
gcloud organizations set-iam-policy ORG_ID policy.json

# Get Policy
gcloud organizations get-iam-policy ORG_ID --format=json

# Remove Policy Binding
gcloud organizations remove-iam-policy-binding ORG_ID \
    --member="group:[email protected]" \
    --role="roles/iam.securityReviewer"
B. Service-specific Resources

For services supporting allow policies for service-specific resources, the command structure follows a consistent pattern across Google Cloud services:

# Add role binding for a service-specific resource
gcloud <service> <resource-type> add-iam-policy-binding <RESOURCE_ID> \
    --member="<MEMBER>" \
    --role="<ROLE>"

# Get allow policy for a service-specific resource
gcloud <service> <resource-type> get-iam-policy <RESOURCE_ID>

# Set allow policy for a service-specific resource
gcloud <service> <resource-type> set-iam-policy <RESOURCE_ID> policy.json

# Remove role binding for a service-specific resource
gcloud <service> <resource-type> remove-iam-policy-binding <RESOURCE_ID> \
    --member="<MEMBER>" \
    --role="<ROLE>"

3. Verification Plan

Depending on which mutating allow policy operation was executed (add-iam-policy-binding, remove-iam-policy-binding, or set-iam-policy), run only its corresponding verification step before reporting completion:

  1. After add-iam-policy-binding:

    • Action: Run get-iam-policy on the target resource (project, folder, organization, or resource).

    • Verification: Ensure the target principal is listed under the assigned role in the policy bindings.

  2. After remove-iam-policy-binding:

    • Action: Run get-iam-policy on the target resource.

    • Verification: Ensure the target principal is no longer listed under the role in the policy bindings (or that the binding is removed if no other members remain).

  3. After set-iam-policy:

    • Action: Run get-iam-policy on the target resource.

    • Verification: Verify that the returned policy matches the full intended policy state defined in the applied policy file.

After verifying the mutating change, remind the user that IAM allow policy changes take up to 7 minutes or longer to propagate across Google Cloud global infrastructure.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Google
Publisher
Google (Official)
Source
google/skills · skills/cloud/iam-helper-for-policy-management · commit 2194d3b
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download iam-helper-for-policy-management.zip