An Agent Can Now Draft Your Google Cloud Guardrails

Google Cloud's Organization Policy service is the guardrail layer: predefined constraints and custom constraints that say what a project, folder, or organization is allowed to look like. In 2026 Google put an MCP server on that service and let Gemini draft constraints in natural language. An administrator can ask an agent what the effective policy is, where it drifts, and, if the identity allows it, to create a policy or a custom constraint. That is a real shortcut for a team that has been copying constraint YAML from a doc. It is also a new principal that can change the rules the rest of the estate is supposed to obey.

The announcement is AI-powered cloud governance. The control that decides whether any of those tools may run is no longer an organization-policy constraint. Google shut that path down. Current control of Google Cloud MCP servers is IAM, documented in Control MCP use with IAM. The two facts have to be read together. One feature invites an agent to administer policy. The other feature is how you stop an agent from calling a tool you did not intend, including a tool that writes.

A VS Code install link that hides the config is a different door, covered in the VS Code MCP bugs. A poisoned tool description in general is in MCP server security. This note is the cloud-governance server: who may draft a constraint, who may apply it, and which tools stay denied on production.

What the Organization Policy server can call

The MCP server exists so an agent does not have to scrape the console to understand a hierarchy. Google's list of tools is the job description.

ListConstraints and GetCustomConstraint tell the agent which guardrails exist on a project, folder, or organization. GetEffectivePolicy computes the policy that actually applies after inheritance and tag conditions. That is the useful read. A constraint set on the organization and overridden on a folder is a fact the console hides in three screens. An agent that can call GetEffectivePolicy can answer "are we actually requiring OS Login?" without a person clicking.

CreatePolicy and CreateCustomConstraint are the write tools. They create the guardrail, they do not merely describe it. Gemini's authoring flow sits on top of the same idea: you describe a requirement in language, and it drafts a custom constraint. The blog's examples are the kind of rule a platform team actually wants — require an agent identity in Agent Runtime, require an approved Agent Gateway, refuse to let someone turn off GKE auto-upgrades — and then refine the YAML by talking. It can also generate a resource that should comply and a resource that should violate, so you can see the constraint fire before you trust it.

Read and write are different approvals. A support agent that may list constraints and read the effective policy is a reasonable assistant. An agent that may create a policy is an administrator. The tool list does not make that distinction for you. IAM does, and only if you set it. A single service account with organization-policy admin, wired into an MCP client because the demo needed it, is an administrator that takes instructions from a prompt.

The draft is still the valuable part. A custom constraint is easy to get wrong, and a test resource that should fail is how you notice. Let the agent produce the YAML and the two test resources. Apply the YAML from a change request a person merges, in the same repo where your other constraints live. A conversational "yes, create it" in a chat window is not that change request. You will not have a diff, you will not have a reviewer, and you will not know which prompt was in the context when the tool fired.

The old MCP constraint is gone

Until March 2026, teams could limit which managed MCP services were allowed with the custom constraint gcp.managed.allowedMCPServices. Google deprecated that control on February 17, 2026 and shut it down on March 17, 2026. If your runbook still says to set that constraint, the runbook is describing a feature that no longer does anything.

The replacement is IAM on mcp.tools.call. A caller that uses a Google Cloud MCP server needs two things: the MCP Tool User role (roles/mcp.toolUser), or another role that contains mcp.tools.call on the project, and the ordinary permissions for the underlying service. The tool permission is not the data permission. You can be allowed to invoke a BigQuery tool and still be denied the dataset. You can be allowed to query the dataset in the console and still be denied the MCP path. Both checks have to pass for the call to succeed.

Non-Google MCP servers are outside this. Google's docs are explicit: IAM deny policies and roles/mcp.toolUser do not govern a server you run yourself, a third-party server, or a local process. The VS Code bugs and a random npm MCP server are not controlled by a Google Cloud deny policy. The deny policy is for Google's servers. Your own servers need the inventory in the MCP note, not a constraint in Resource Manager.

There is a second limit inside the feature. mcp.tools.call is checked at the project. MCP attributes in IAM conditions cannot control resourceless APIs such as the Resource Manager MCP server. If the tool you are worried about administers the hierarchy itself, read that exception before you assume the deny you wrote covers it. Resource Manager is the service that contains the projects. A hole there is not a niche.

Deny policies are the brake

IAM deny policies can match attributes of the MCP call, not only the person. The attributes Google documents are tool.isReadOnly, request.auth.oauth.client_id, resource.service, and tool.name. A deny that matches tools where tool.isReadOnly is false is the production brake: the agent may list and get, and it may not create, delete, or update. A deny on resource.service can refuse MCP into BigQuery, or into compute, while leaving another service alone. A deny on tool.name refuses one tool. A deny on the OAuth client id refuses a particular application even when the user would otherwise be allowed.

The limits on those attributes are easy to miss, and they are in the same doc. request.auth.oauth.client_id works on deny policies and not on allow policies. The attributes are only evaluated for mcp.tools.call. You cannot mix them with an unrelated permission in the same deny and expect the MCP condition to apply to both. You cannot mix tags with resource.service or the other MCP attributes in one condition. resource.service and tool.name do not appear in the console. Policies that use them are applied with the gcloud CLI, from a policy file, attached to the project, folder, or organization.

That CLI-only detail is how the control rots. A security reviewer looking at the console sees no MCP condition and concludes there is no MCP policy. The policy is in a JSON file someone applied last quarter. Put the policy file in the repo. Review the diff. Do not let the agent that holds CreatePolicy also be the only place the deny file exists.

Google's own safety page for MCP, AI security and safety, says the quiet part. A trusted server can add tools later. Your agent gains a capability because the server grew one. The mitigation they list is periodic review of the tool list, an allowlist such as Gemini CLI's coreTools, a deny that blocks read-write tools on production, and a content check such as Model Armor on inputs and outputs. A deny on non-read-only tools is the control that still works when the server adds a tool you have not seen. An allowlist of tool names is the control that works until the name changes. Use the deny for production. Use the allowlist on the client so a development agent does not even see the write tools.

Agent identity is the other half of that page. Create an identity for the agent. Grant it the roles the task needs. Do not run the MCP client as a human owner who clicked a login once and left the refresh token in a config file. A human owner's token plus CreatePolicy is a standing administrator. An agent identity that can only call read-only tools on one project is a tool you can lose without losing the organization.

What "let the AI manage policy" should mean

The useful delegation is narrow. Let the agent read effective policy, list constraints, and draft a custom constraint plus a pair of test resources. A person who understands the hierarchy reads the draft, applies it through the change process, and watches the non-compliant test resource fail. Gemini authoring is a faster way to get to that draft. It is not a faster way to skip the person.

The delegation that fails is "keep us compliant." Compliance is a state of the resources. An agent with a write tool will get there by creating exceptions, widening a constraint, or writing a policy at the wrong node of the hierarchy so the effective policy looks green and the project you care about is exempt. GetEffectivePolicy is how you check the agent's work. It is also a tool the agent can call before it writes, which means a malicious or confused prompt can search for the exemption that already exists and aim the next change at the folder where the constraint is weakest. Read tools are not harmless when they scout a later write. They are still the right tools to allow. The write stays in a separate identity, used from a pipeline, not from the chat.

Separate the OAuth client too. The deny attribute for client id exists so the agent's client can be refused even when the user is an editor. Use it. The client id of an interactive admin CLI and the client id of an agent runtime should not be the same registration. A deny that names the agent client, attached at the organization, beats a hope that the agent will only be installed in the sandbox project. People copy configs. The deny travels with the org. The config travels with a laptop.

Do not ask the agent to design the deny that binds the agent. That is the policy protecting the policy. A human writes the production deny, in the repo, and the agent is subject to it. If the agent's identity can edit that deny, the subject and the author are the same principal and you are back to a prompt. The identity split for the agent and the user is the same idea on AWS. The principal that enforces is not the principal that chats.

Logs matter because a conversational apply does not leave a pull request. Turn on the audit logs for organization-policy changes and for MCP tool calls if your sink supports them. When a constraint appears, you want the identity, the tool name, and the time. "Someone was using Gemini" is not an audit. An agent identity in the log is.

A production split that is boring enough to keep

Development projects may allow a broader tool list for the platform team, on an identity that cannot touch production folders. Production projects get mcp.tools.call only for read-only tools, denied by policy at the folder, not by a setting inside the chat product. Custom constraints are applied by the pipeline that applies the rest of your infrastructure, from a reviewed file. The agent opens the pull request. It does not approve it. It does not have a second token that skips the pipeline.

Test the deny. Call a write tool with the agent identity and expect the denial. Call a read tool and expect success. A policy nobody has triggered is a policy you will discover during the incident, when the agent was allowed after all because the attachment point was the wrong project. Google's note that some attributes are CLI-only means the test should use the API, not a glance at the console.

Revisit the tool list when Google adds tools to the Organization Policy server. A new write tool inherits whatever your IAM allows. A deny on "not read-only" still covers a tool you have not read about. A list of blessed tool names does not. Prefer the attribute that stays true when the catalog grows.

Exemptions are the other way a guardrail disappears without a delete. Organization policy allows exceptions on a resource, often with a reason and an expiry that nobody reads again. An agent asked to "unblock the deploy" will find the exemption tool if the identity has it, write an exception on the production project, and report that the deploy is compliant. The effective policy on that project is then the exception. GetEffectivePolicy on the project, not on the organization, is the check that sees it. Put exemption creation with the write tools: denied for the chat identity, allowed only in the pipeline, with an expiry you have alarmed. An exemption without an expiry is a second policy that wins forever.

The same habit shows up when Gemini drafts a constraint that is correct and attached at the wrong node. A constraint on a sandbox folder does not bind production. A constraint on the organization with a tag condition nobody matches does not bind production either. Ask the agent for the attachment point in the draft, and require GetEffectivePolicy output for the production project in the pull request. A YAML file with no effective-policy paste is a proposal. The paste is the evidence the node you chose is the node that governs the resources.

What to check before an agent can see Organization Policy

1. Confirm gcp.managed.allowedMCPServices is not your control. It shut down on March 17, 2026. Find the IAM deny that replaced it, or accept that you do not have one.
2. List the identities that have mcp.tools.call and organization-policy write permissions. An agent identity with both is an administrator.
3. Put a deny on non-read-only MCP tools at the production folder. Store the policy file in git. Remember the console will not show tool.name or resource.service conditions.
4. Use a distinct OAuth client for the agent and deny that client where the chat should not operate.
5. Let the agent draft constraints. Apply them from a reviewed change. Do not grant CreatePolicy to the identity that chats.
6. Run one write call that must fail and one read call that must succeed. Save the denial.
7. If you cannot find the deny file, the agent can do whatever the user who logged in can do. That is the answer, and it is the problem.

A draft from Gemini is a head start on a constraint. The apply is a change to the estate. Those are not the same click.

How Techtribe reviews an agent that can change cloud policy

We read the project and the policy files, and we separate identities that may draft a constraint from identities that may apply one. You get the deny policies and the tool list in writing, including whether a write tool would succeed from the agent. We do not add a sentence to the prompt and call the guardrail done.

A one-time pass fits when a platform team turned on the MCP server to try it. A Dedicated Team fits when that identity is already in production and new tools keep showing up. The scope call is 30 minutes with a founder, and it is where we say which you are in.

Bring the project and whether an agent identity can call CreatePolicy or another write tool. If it already has, say that first so the call starts from the change log rather than from the demo.

The fixed scope for taking a generated app to production is a page per tool: Lovable, Bolt, v0, and Replit.