Google's Data Agent Kit Splits Agent Guardrails Between Advisory Skills and IAM Deny Policies, and InfoQ Lists Three Limits

Overview

Google’s Data Agent Kit, which connects coding agents to Google Cloud data products, ships two different kinds of guardrail: instructions the agent is asked to follow, and policies Google Cloud enforces. InfoQ describes the split in a report dated October 24, 2026, and Google’s IAM documentation spells out where the enforceable half stops.

What the kit is

A Google Cloud blog post dated September 30, 2026 says Data Agent Kit is generally available and describes it as “a free set of Model Context Protocol (MCP) tools and agent skills” that lets a coding agent work with Google Cloud data products. The post names Antigravity, Claude Code and Codex among the supported tools. With general availability, it says, Google added support for BigQuery Graph, Bigtable, and Managed Service for Apache Spark.

The post lists two components. MCP tools give “Connections to more than 15 Google Data Cloud services”, and Google-authored skills teach “data best practices, like optimizing BigQuery SQL, designing Bigtable row keys, and building dbt (data build tool) pipelines.” On cost, the post says the kit “is included at no additional cost; you pay standard pricing only for the Google Cloud services your agent uses.”

According to InfoQ, the plugin repository carries 37 skills under Apache 2.0, with version 1.0.0 cut on September 29 and 1.1.0 on October 13. The repository’s releases page also lists a v1.2.0 dated 30 Oct, whose notes include “add cloud_databases_onboarding skill and evalbench suite to Data Agent Kit.”

The advisory half: skills

One skill, accidental-data-loss-prevention, targets destructive operations. Its definition file opens with “STOP AND VERIFY” and says the agent must “obtain explicit user consent” before any command or tool that results in irreversible data loss. It lists SQL such as DROP TABLE and TRUNCATE, a broad DELETE, and infrastructure actions including gcloud projects delete and KMS key destruction. The mandatory procedure is to halt execution, explain the impact and the reason, and wait for the user’s approval.

InfoQ’s characterization is blunt: “That guardrail is advice. The agent is asked to obey it.”

The enforceable half: IAM deny policies

InfoQ reports that Jeff Nelson, whom it describes as a developer advocate, answered a question about isolating read-only investigation by pointing to IAM rather than to per-agent settings: run the agent as a read-only service account through impersonation, or use “an IAM deny policy that blocks any MCP tool where tool.isReadOnly is false.”

Google’s documentation says IAM deny policies “let you restrict Model Context Protocol (MCP) tools to read-only actions” and can be applied at the organization, folder or project level. Its example condition is api.getAttribute('mcp.googleapis.com/tool.isReadOnly', false) == false, attached to the mcp.googleapis.com/tools.call permission. The Google blog post separately says the agent connects as the user or as a service account the user impersonates, so row- and column-level security policies apply automatically, and that administrators can also screen MCP traffic with Model Armor and scope agents with VPC Service Controls.

Documented limits

InfoQ lists three limits, each of which also appears in Google’s documentation:

• Blocked tools still appear. The documentation notes that when an MCP client calls tools/list, “a list of all tools is returned, including read-write tools.” InfoQ says the agent therefore finds out only on invocation.
• Scope is Google Cloud MCP servers. The documentation states: “You can’t use IAM deny policies to control access to MCP tools provided by non-Google Cloud MCP servers.”
• Some attributes are CLI-only. The resource.service and tool.name attributes are not available in the Google Cloud console, and policies using them “must be managed with Google Cloud CLI.”

Practitioner reactions

InfoQ quotes several practitioners with different emphases. Amel Habira, an AI solutions architect, was encouraged by the short-lived credentials, the read-only attribute and a warning before agents execute notebook cells. Ankit Dongre, an AI engineer at viaSocket, wrote: “MCP access is the easy part. The production boundary is permission scope plus repeat-safe execution: what happens when an agent retries a write after a timeout, or when the schema changes mid-run?” He added that IAM and dry runs “do not tell the agent whether a timed-out write committed.” InfoQ states that Data Agent Kit’s tool results do not carry an idempotency key, commit status and rollbackability today.

Timon Knapp, founder of the workload automation vendor Conductral, wrote that he would start “with read access and suggestions” and let “a human confirm anything that changes a schedule or reruns a job.”

InfoQ also contrasts the approach with Microsoft’s Agent 365 integration with Azure API Management, which it says is in public preview and enforces governance at a gateway, where per-tool blocking requires a preview tier.

What We Don’t Know

The cited sources do not say how many Data Agent Kit users have deployed deny policies. The InfoQ report is the only independent account among the sources cited here; the Google Cloud pages and the plugin repository are the vendor’s own.