How to give AI agents secure access to your data

The discussion around securing AI agents that work with data gets complicated because people mean different things by “security.”

Some see it purely as a legal question: where data is processed, how long it is retained, and the risk of GDPR penalties. Others worry about data disclosure. Then there are operational risks: an agent can corrupt data, cause an outage, or drive BigQuery costs far above their usual level.

There is no single right approach I can lay out so that you can tick security off as solved. Every company has to decide what is acceptable for itself. And that decision really does have to come from the company—not Frank in purchasing, who decides to let Claude Code into the company database without further ado, or Jane, an external social media manager who lets Codex analyze campaign results. Either use case may be completely fine at one company and unacceptable at another. That is why Frank and Jane can't make the call on their own.

I don't think the decision should be left entirely to security, either. That would naturally optimize for minimum risk, which is too narrow a view. From the start, people from the business, legal, security, and ideally data teams should define the boundaries together. Executives and business owners weigh potential risk against benefit; legal sets out the limits imposed by law and contracts; security assesses feasibility and effort; and data specialists provide essential context on sensitivity, anonymization, and pseudonymization.

From a security perspective, built-in AI agents are generally much easier to manage: think Vertex AI in GCP and Gemini in BigQuery, Microsoft Foundry Agent Service with Fabric data agents, or Amazon Bedrock AgentCore. The moment you connect Claude Code, Codex, or local models outside an integrated platform, you add another layer of complexity.

Agent guardrails

You probably suspect that a system prompt, AGENTS.md, CLAUDE.md, or similar file where you politely ask the agent—or emphatically forbid it—to do something is not quite enough (see this report in The Guardian). Unless you set truly insurmountable technical limits, you are merely playing the odds on whether and when something goes wrong. External AI agents working with data make matters even more complicated because they automatically fulfill all three parts of the lethal trifecta: access to sensitive data, exposure to untrusted content, and the ability to communicate externally.

Those are also the three areas we will try to constrain technically: what the agent can see, what it can do, and what else it can access.

Let's start with the most common—and worst—possible approach. We run the agent from our computer's terminal without an isolated sandbox. We log in to the database with our personal account. The agent can access both the database and a Slack MCP, with no restrictions on the tools it can call or where it can go on the internet.

If the agent is compromised, it may be able to do far more than we intended: modify any table available through our credentials and use its unrestricted network access to send data outside our controlled environment through services we have not approved.

We can also run into trouble when the agent works exactly as intended. Because we haven't set any limits on querying the data, we may notice the damage only when the GCP invoice lands.

A production approach is several orders of magnitude more complex, especially if we want the agent to do more than query data while we actively work with it. It may have recurring tasks of its own: detecting anomalies, recommending changes to marketing campaigns, updating remarketing lists, or updating a prediction model.

In that case, we want each agent to have access to a different part of the dataset. The general aim is to minimize potential damage by giving each purpose the absolute minimum access and data it needs. We also need to monitor what every agent actually does and evaluate afterward how well it performed, whether it followed the established procedure, and how much each activity cost in tokens and data processing. If we don't give each agent or task a trusted identity or context at the outset, telling them apart later will be difficult—and debugging after the fact will be hell.

The system has three levels of guardrails: restrictions on the agent runtime (Docker isolation, closed ports, and access only to the tools it strictly needs); restrictions in the MCP itself (identity-aware routing and narrow operations, such as read-only queries with a dry run); and restrictions in the GCP account (access to individual tables, data masking, per-query limits, and especially QueryUsagePerUserPerDay).

When guardrails are not enough

When designing a security policy, we shouldn't assume we can prevent everything in advance. We may underestimate something or fail to consider it at all, and running agents is a different discipline from running even a highly complex script. Agents will surprise you with their ingenuity—and with remarkable regularity.

_That is why, for example, I mentioned QueryUsagePerUserPerDay, a cumulative limit per agent. If we limit only the size of an individual query and the agent finds that one query isn't enough to complete the task, it will call the query again with small changes. Say, 2,000 times. Yes, we've seen that too._

We need a way to track what the agent does, what it asks of the data, and what happens in GCP—and to respond either manually or automatically. In some cases, we can stop the agent the moment it tries to do something it shouldn't by rejecting a specific tool call. In others, the available controls mean we can intervene only while the action is underway, by canceling a running BigQuery job, or after the fact. Even then, revoking access or using another kill switch can minimize the damage.

Here again, built-in AI agents often come with all or most of this infrastructure, saving you a considerable amount of work.

If the agent can stay within your data warehouse and the capabilities included with an integrated platform meet your needs, using a built-in agent is usually the simplest option. This does not mean you can skip the earlier exercise: a built-in agent is not automatically safe to use with data. But once the company has set its boundaries, an integrated platform can make them easier to enforce.

As soon as you want an agent to work across BigQuery, ad platforms, Slack, or internal APIs, the data warehouse security layer alone is no longer enough. You must either add equivalent controls for a built-in agent that reaches external systems or manage the broader integration through an external agent. Keeping every agent inside a very narrow slice can constrain the work agents can do, so the right boundary depends on the task and the controls you can operate reliably.

What's next?

I spoke about monitoring AI agents working with data at the AI Bootcamp and MeasureCamp London. You can look through the presentation, although I'm afraid the slides alone won't tell you all that much.

And if you'd like to explore security for AI agents working with data in more depth, you can buy a recording of our online training (on our Czech site).