Skip to main content
Marcus’s three questions are still in your inbox:
  • Whose credentials is the agent using?
  • What can those credentials actually do?
  • What stops it from running a DELETE query?
We ran five comparisons and they came out even. The next step is to answer those three questions, because the safety rule that matters in production is: govern credentials, not the prompt.

Whose credentials is the agent using?

You gave the toolbox your Application Default Credentials:
That hands the toolbox your Application Default Credentials (ADC). ADCs inherit everything you can do: read, update, delete — any action your account permits. So what stops the agent from running a DELETE? Right now: nothing.
A slide diagram titled "Whose Credentials?" showing arrows from "Your Credentials" through a "Toolbox" to a red "DELETE" button, asking "What stops it from running a delete?" The slide implies the answer: "Nothing does."

Why prompt-based guards fail

A polite instruction in the prompt is not a security control. For example, this prompt-based guard is ineffective:
An instruction is only a suggestion the model will usually follow — not an enforced constraint. If a DROP TABLE query is possible and the agent has credentials that allow it, a prompt line is a hope, not a control.

The real fix: govern credentials with least privilege

Create a dedicated service account for the toolbox and grant only the minimal roles it needs. Do not use your ADC or personal credentials for open-ended agents. Recommended minimal roles for a read-only analytics agent: Give no write roles and no admin roles. With only these permissions, a DELETE or DROP will be refused by BigQuery because the service account does not have write privileges.
A diagram titled "The Real Fix – Govern the Credential" showing a flow from a Toolbox icon to a Service Account (key) and then to BigQuery. It lists restricted permissions for the service account: Data Viewer and Job User, with no write or admin roles.
That refusal is exactly the behavior Marcus should see: the agent may generate a DELETE, but BigQuery will reject it because the service account lacks the required permission.
Give the agent the least privilege it needs. Use dedicated service accounts or keys with read-only permissions for open-ended queries, and reserve write permissions for tightly controlled tooling.

Decision guide: Function tool vs MCP-style toolset

When should you lock functionality behind a fixed function tool vs. provide an open-ended toolset (MCP-style)? Use a function tool when you must guarantee a particular action (especially writes). Use an MCP-style toolset for read-heavy, open-ended questions where the same controlled data surface is shared across agents or applications. The two approaches can be composed — for example, an agent might use an MCP read toolset for exploration and call a function tool for a single allowed write. Learn more about MCP patterns here: MCP-style toolset
A slide titled "A Decision Guide" showing two side-by-side boxes: "Function Tool" on the left and "MCP" on the right. The left box features a green wrench icon and bullets about billing actions, approved queries, and anything that writes data, while the right shows an orange server icon.

One more point: avoid single-warehouse blind spots

All of the agent’s answers so far came from a single warehouse: BigQuery. That gives you a narrow view of the customer.
A simple flow diagram titled "Half a Customer" showing "Claire's First Email" (mail icon) sent to a "Churn Agent" (robot icon). The churn agent then outputs data into BigQuery (hexagon icon).
Example: usage has collapsed in five support tickets — and then it stops, because BigQuery only has five events. The agent never read the tickets themselves, so it doesn’t know ticket tone, category, or closure state. Other teams keep data in Databricks or in ticketing systems; relying on one warehouse (BigQuery) yields a partial — often misleading — customer profile. Address this by:
  • Consolidating relevant sources into the controlled MCP surface, or
  • Allowing dedicated read-only connectors for each source the agent should consider, with governed credentials for each connector.
Summary checklist
  • Do not give agents your personal ADCs for open-ended access.
  • Create dedicated service accounts with least privilege (bigquery.dataViewer, bigquery.jobUser) for read-only agents.
  • Use function tools for any write or billing-sensitive action.
  • Combine MCP-style read toolsets with tightly controlled function tools when both exploration and a single allowed write are needed.
  • Ensure agents can access all relevant data sources (not just one warehouse) to avoid partial or incorrect conclusions.

Watch Video