Set up the Google Cloud IAM MCP server
Google Cloud's IAM MCP server lets AI agents manage custom IAM roles (create, update, delete, undelete) and IAM v2 deny policies that block principals from using specific permissions. This guide walks through enabling the IAM API, granting IAM roles to users, creating an OAuth client in Google Cloud, and connecting the server to MintMCP.
Prerequisites
- A MintMCP admin account
- A Google Cloud project with billing enabled
Enable the IAM API
- Go to console.cloud.google.com/apis/enableflow?apiid=iam.googleapis.com and select your project.
- On Confirm project, check that the correct project is selected and click Next.
- On Enable API, click Enable. Enabling the IAM API also enables its MCP server.
Grant IAM roles
Each user who connects to IAM through MintMCP needs IAM roles, granted at the project, folder, or organization level depending on where their custom roles and deny policies are scoped.
- Go to console.cloud.google.com/iam-admin/iam and select your project, folder, or organization.
- To add roles to a user already listed, click the edit (pencil) icon on their row. To add a new user, click Grant access and enter their email address or a Google Group.
- Add the roles, clicking + Add another role for each:
- MCP Tool User (
roles/mcp.toolUser) to make MCP tool calls - Role Viewer (
roles/iam.roleViewer) to list and inspect custom IAM roles - Deny Reviewer (
roles/iam.denyReviewer) to list and inspect IAM deny policies - Role Administrator (
roles/iam.roleAdmin), only for users who should create, update, delete, or undelete custom roles - Deny Admin (
roles/iam.denyAdmin), only for users who should create, update, or delete deny policies
- MCP Tool User (
- Click Save.
Users without a role for an operation get an authorization error when they call the matching tool, so you can keep most users on the viewer roles and reserve the admin roles for the few who manage roles and deny policies.
Create an OAuth client
The OAuth client gives MintMCP a Client ID and secret to broker each user's Google sign-in. Create one Web application client and point its redirect URI at MintMCP's callback.
-
Go to console.cloud.google.com/auth/clients and select your project.
-
If prompted to configure the OAuth consent screen, set the user type to Internal (Google Workspace organizations only). This restricts access to users in your org and skips Google app verification, which is otherwise required for the IAM scope.
-
Click Create client.
-
Set Application type to Web application and give it a name (for example,
MintMCP OAuth).
-
Under Authorized redirect URIs, click Add URI and enter:
https://app.mintmcp.com/oauth/callbackLeave Authorized JavaScript origins empty. This URI must match the Redirect URL in the connector's OAuth settings exactly, or sign-in fails with
redirect_uri_mismatch.
-
Click Create. Google shows the Client ID and Client secret once, so copy both now: you can't view the secret again after closing the dialog.
Reopen the client anytime from the Clients list to edit its redirect URIs or rotate the secret.
Add Google Cloud IAM to MintMCP
- In MintMCP, go to MCP store → Manage store.
- Find Google Cloud IAM in the recommended servers list and click Install.
- Open the connector's OAuth settings and enter the Client ID and Client secret from the OAuth client you created.
- Confirm the Redirect URL shown in the connector's OAuth settings matches the URI you added to the OAuth client (
https://app.mintmcp.com/oauth/callback). They must be identical, or sign-in fails withredirect_uri_mismatch. - Click Install.
The first time a user calls a tool, MintMCP directs them to sign in with Google and consent to the IAM scope. MintMCP stores and refreshes their token automatically on every subsequent call.
Security considerations
- Access is controlled by Google Cloud IAM: users without the required roles receive an authorization error when connecting, and write tools require the Role Administrator or Deny Admin role on top of the viewer roles.
- Each user authenticates individually with their own Google account, so all operations run under their identity and appear in Cloud Audit Logs.
- Deny policies take effect immediately and can block access across the resource hierarchy, including for administrators, so review a policy's rules before creating or updating one.
- The server exposes destructive tools (
delete_role,delete_deny_policy). Restrict them by keeping most users on the viewer roles, with tool customization in MintMCP, or with IAM deny policies, see Control MCP use with IAM. - Admin Activity audit logs are on by default for IAM API role and deny-policy changes and can't be disabled. Enable Data Access audit logs on the IAM API to also capture read operations.
Next steps
- Control MCP use with IAM — Restrict which tools users can call with deny policies
- Custom roles — Learn how custom IAM roles work
- Deny policies — Learn how IAM deny policies work
- Tool customization — Control which IAM tools are exposed to users
- MCP gateway administration — Manage access and permissions