Create the credential in Google Cloud
Create a dedicated service account for the agent in the Google Cloud project that holds your BigQuery data, then create a JSON key for it. Google’s guides cover creating a service account and creating a service account key.Grant access to specific datasets
You scope what Claude can read on the Google Cloud side, through the service account’s role grants. The connector itself has no dataset setting. Grant the service account two roles:- BigQuery Data Viewer (
roles/bigquery.dataViewer) on each dataset Claude should query. Grant it on the specific datasets, not on the project, so Claude can read only those datasets. - BigQuery Job User (
roles/bigquery.jobUser) on the project, so the service account can run query jobs.
Add the connector
Go to Organization settings > Claude Tag > Connectors, click Add, and select BigQuery. The first credential you add for a service from the Connectors tab is on in every workspace and channel as soon as you save it. To give it narrower reach, see where a new connector applies before you save the connector. In the connect form, paste the whole JSON key file from Google Cloud Console into Claude’s service account key (JSON), then click Connect to save the connector. The access tokens Claude gets from this key carry only Google’scloud-platform.read-only scope, so Google refuses BigQuery API calls that create or delete tables or run load jobs. Queries still run with whatever the service account’s roles allow, so the dataset roles decide what a query can reach.
Agent Proxy exchanges the service-account key for an access token and injects it at the network boundary; the model and the sandbox are not given the key. See how Agent Proxy works.
Verify the connection
In a channel where the connector is on, in a new thread:Allow the connection through a VPC Service Controls perimeter
If the Google Cloud project that holds your BigQuery data is inside a VPC Service Controls perimeter, Claude’s queries fail withRequest is prohibited by organization's policy and a vpcServiceControlsUniqueIdentifier in the error details. To let them through, add an ingress rule that admits the service account you created for Claude.
If you allowlist Anthropic’s published egress IP range in an access level, Claude’s queries still fail, because they reach your perimeter from inside Google Cloud rather than from that range. The source your perimeter sees is a Google Cloud project that Anthropic owns and can change without notice, so don’t admit that project by its number.
Add an ingress rule to the perimeter with these settings:
- For the identity, admit the service account you created for Claude.
- For the source, allow any source (an access level of
*). - For the target, allow the BigQuery API (
bigquery.googleapis.com) on the project inside the perimeter.
What the VPC Service Controls ingress rule allows
The ingress rule lets requests authenticated as the service account you created for Claude cross the perimeter, and only to reach BigQuery in the project the rule names. It doesn’t give the service account access to any data. The dataset roles you granted still decide which datasets Claude can read, so keep those grants narrow. Once the connection works, delete the key file that Google Cloud downloaded to your machine when you created the key. With this rule in place, the perimeter doesn’t stop a leaked key for this service account, because a request authenticated with any of the account’s valid keys passes the rule from any source. Agent Proxy holds the key you uploaded and Claude never sees it. To limit that risk further, don’t create more keys for the service account.Related resources
- What this connection adds: warehouse questions answered with charts in the thread
- Give Claude access: the full credential-type and allowed-hosts reference