Google takes Data Agent Kit out of preview and splits agent guardrails between skills and IAM

What Is Data Agent Kit

Data Agent Kit is a set of MCP (Model Context Protocol) tools that connects coding agents to more than 15 Google Data Cloud services, according to Google's announcement. Along with the tools come skills written by Google itself, covering best practices such as optimizing BigQuery SQL or designing row keys for Bigtable.

The toolkit runs in editors such as Antigravity, Claude Code, Codex, Cursor and any VS Code-compatible environment, and comes pre-installed in Cloud Shell and Cloud Workstations. It's free beyond the cost of the Google Cloud services consumed, and the skills repository is open source under the Apache 2.0 license.

Product manager Arun Nair and developer advocate Jeff Nelson, authors of the launch post, sum up the problem the kit tackles: agents write reasonable SQL, but they don't know which tables exist, how they're partitioned, which ones the team trusts, or why last night's job failed.

From Preview to GA

Data Agent Kit ran in preview throughout the 2026 North American summer before reaching general availability (GA), according to InfoQ. With GA, Google added support for BigQuery Graph, Bigtable and Managed Service for Apache Spark, expanding the list of services covered by the 15 integrations already in place.

The skills repository has formal versioning: 1.0.0 was released on September 29, 2026, and 1.1.0 on October 13, 2026. This lets teams pin a specific version in production instead of depending on a main branch that changes without notice, a practice already common in CI/CD pipelines but unusual in generative AI kits.

Two Types of Guardrail, Two Levels of Guarantee

The point that matters most for anyone putting this into production is the distinction Google draws between two kinds of control. One of the 37 skills in the repository, called accidental-data-loss-prevention, exists to stop the agent from accidentally destroying data.

Its description opens with "STOP AND VERIFY" and instructs the agent to obtain explicit user consent before any irreversible action, listing DROP TABLE, TRUNCATE, a DELETE without a WHERE clause or with 1=1, deleting production buckets, gcloud projects delete, and destroying KMS keys. The procedure is to stop, explain the impact, and wait for confirmation.

This guardrail is advice. The agent is instructed to follow it, but nothing technically stops it from ignoring the instruction if the model misreads the context. A second control, this one, does not depend on the model's good will.

The Technical Lock Sits in IAM

Asked in a LinkedIn post whether it would be possible to isolate read-only investigation from the tools that change infrastructure, Nelson replied that this is solved in IAM, not per agent:

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.

Jeff Nelson, developer advocate at Google Cloud

Google Cloud's documentation shows the exact condition used in this deny policy:

api.getAttribute('mcp.googleapis.com/tool.isReadOnly', false) == false

It denies the mcp.googleapis.com/tools.call permission and can be applied at the organization, folder, or project level, with additional attributes for resource.service and tool.name.

Three Limits That Remain Open

The approach has gaps that anyone implementing it needs to know before blindly trusting the mechanism:

• A blocked tool still shows up in tools/list: the agent sees the capability and only discovers it can't use it when it tries to invoke it.
• The controls cover only Google Cloud MCP servers, nothing beyond that.
• The resource.service and tool.name attributes exist only via gcloud, absent from the console.

Another point raised by experts is what happens after the permission lock. Ankit Dongre, AI engineer at viaSocket, argues that MCP access is the easy part of the problem:

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?

Ankit Dongre, AI engineer at viaSocket

For Dongre, IAM and dry runs cover authorization and upfront verification, but they don't tell the agent whether a write that timed out was actually committed. He argues that a tool result should carry an idempotency key, commit status, and an indication of whether the operation can be reversed, something Data Agent Kit doesn't yet deliver.

Early Testers React With Cautious Optimism

Amel Habira, AI solutions architect, read the documentation and highlighted short-lived credentials, the read-only attribute, and a warning before the agent executes notebook cells:

Combine that with branching and time travel on the Iceberg side, and you can imagine containment at both the access layer and the data layer.

Amel Habira, AI solutions architect

Timon Knapp, founder of Conductral (a self-hosted workload automation tool), recommends a more conservative path for those connecting agents to systems like Airflow:

Connecting agents to live environments like Airflow is powerful. From running production batch for years I would start with read access and suggestions, and let a human confirm anything that changes a schedule or reruns a job. A clean audit trail makes it much easier to give the agent more rights later.

Timon Knapp, founder of Conductral

How This Compares to What Microsoft Is Doing

Microsoft solved the same problem a different way with the integration of Agent 365 with Azure API Management, now in public preview. The approaches diverge on where the decision sits and at what level it's applied:

What Changes for Developers in Brazil

For Brazilian teams already using BigQuery, Vertex AI, or Bigtable, Data Agent Kit removes part of the work of writing MCP integrations from scratch: the connection to the live schema and the best-practice skills come ready-made and versioned, installable in Cursor, Claude Code, or VS Code at no additional cost beyond Google Cloud usage.

But the real news for anyone putting this into production isn't the convenience, it's the division of responsibility: the data-loss prevention skill is just a prompt instruction, one the model can ignore under context pressure. The lock that actually prevents an improper DROP TABLE needs to be manually configured as a deny policy in IAM, using gcloud, since the attribute doesn't appear in the console.

Platform teams considering letting agents explore production data should treat this IAM configuration as a prerequisite, not an advanced option, and consider Knapp's advice to start with read-only accounts before enabling any writes.