Google’s Data Agent Kit can mistake warehouse data for instructions—so IAM alone is not the safety boundary

Google Cloud’s Data Agent Kit puts coding agents close to production data: its plugin works with Claude Code, Codex CLI, Gemini CLI and Antigravity, while the product can query or manage resources across BigQuery, Cloud Storage, Spanner, AlloyDB and Cloud SQL. Google’s security guidance makes the consequence explicit: a local coding agent generally operates with the privileges delegated by its user, but can misread data as instructions.

That means the threat is not limited to a hostile prompt typed into the agent. Google says malicious instructions can be planted indirectly in email, calendar content, Cloud Storage or BigQuery, then encountered by an agent that has authority to act. For enterprise data teams, the warehouse itself therefore becomes part of the prompt-injection surface.

Permissions are necessary, but they do not distinguish data from commands

The kit’s permissions page follows a service-by-service model. BigQuery use can involve BigQuery User, BigQuery Data Viewer, lineage-viewer and catalog-viewer roles; database integrations pair viewer roles with database-user or reader roles. The extension checks selected integrations for missing APIs and permissions, while the command-line plugin uses both Google Cloud CLI credentials and application default credentials.

Those controls bound what an identity may reach. They do not determine whether text retrieved from an allowed table or object is evidence or an instruction. That is why Google’s mitigation page adds controls outside ordinary IAM.

Google recommends four containment layers

First, Google recommends running agents in a constrained environment, naming Cloud Workstations without internet access or root privileges and protected with VPC Service Controls as the canonical example. Second, an Organization Restriction Header can prevent access to resources outside approved Google Cloud organizations when traffic passes through a compatible enterprise proxy.

Third, Principal Access Boundaries can limit the resources available to either a dedicated agent identity or a human identity whose authority is delegated to the agent. Google notes the tradeoff: applying the boundary to the human also constrains that person. Fourth, Model Armor can inspect data returned through Google-managed MCP servers and detect or block potential prompt injection.

The operating lesson is straightforward: granting a coding agent read-only warehouse access reduces destructive capability, but it does not remove indirect prompt injection. A defensible deployment combines least-privilege roles with constrained execution, egress controls, resource boundaries and inspection of retrieved content. Teams evaluating Data Agent Kit should test hostile strings inside permitted tables and objects—not just adversarial chat prompts—before treating the agent as production-ready.