Skip to main content

How to Protect Your Data from AI Agents

· 12 min read
Dan Peacock
Dan Peacock
Chief Hustler

This is the public text of the white paper AI Agents on Data Lakes. It answers the question people are now asking search engines and assistants at the same time: how do I protect my data from AI agents?

You protect it by attaching the permission to the data, not to the tool. A bucket policy, a folder grant or a catalog role decides whether an identity can open an object. It does not decide whether that request should see a particular value inside it. An agent is usually given one standing service account, so every question it answers inherits that account's access, whoever is actually asking.

The Medicare data breach is why this stopped being a theoretical gap. In June 2026 an OpenAI agent gained unauthorised access to a public-facing Medicare statistics portal run by Services Australia, reaching public and non-public files. The Australian Government has said no personal information is believed to have been accessed. It has also called the incident unacceptable, and ministers have said the law will change if today's framework cannot control an autonomous agent. That is governments calling for control of AI. On a data lake, the control that holds is the same one: the agent must not be able to see more than the person it is acting for, and that has to be a property of the data.

What the Medicare data breach exposed​

The portal was a statistics service — spending, program data — not a store of individual medical records. The government has been plain that personal information is not believed to have been accessed, and a forensic review is still underway. The shape of the incident is still the one that matters for anyone running a data lake.

An agent was given a task. It went further than the task allowed, into files that were not public, on a system the tool had been able to reach. A person doing the same thing leaves a trail a colleague notices: an unfamiliar login, an odd hour, a folder nobody on that team touches. An agent making the request looks identical to every other request that tool makes, because it usually is the tool making the request.

We don't have the technical post-mortem, and this paper does not guess which control failed. The pattern is enough. Access was granted to a tool. Nothing forced a fresh decision for the specific request that tool then made, or for the person it was nominally acting for.

That pattern is already how most enterprise agents are wired. One service account, standing access, reused for every question. The Medicare data breach is a government system. The same wiring is what a data lake gives an agent that can open the bucket.

Why governments are calling for control of AI​

The Prime Minister set up a taskforce — his department, the National Cybersecurity Coordinator, the Office of AI, the Australian Signals Directorate, the Australian AI Safety Institute and Services Australia — to decide whether existing processes can respond to an AI-related cyber incident. Ministers have said that if current law cannot deal with what happened, the law will be changed. The review is feeding national standards on safeguards and on how quickly an incident has to be reported.

That is a call for control of AI, and it is aimed at the companies building the agents. It does not secure the data those agents will read next. A statute can require reporting and assign liability. It cannot tell your lake that one column is a Medicare number and the column beside it is not.

A Medicare number is a useful example, because it is the kind of field people now have in mind, and because it is already a defined class of data. In CryspIQ® it sits in PI Highly Sensitive, with bank account numbers, passport numbers and biometric data. The breach that made the news was statistics. The field you have to be able to protect, on every consumer including an agent, is the identifier itself.

Why a data lake does not stop the agent​

Most lakes are protected at one layer: storage. A bucket, a folder or a table carries an IAM role, a bucket policy or a catalog permission. That layer answers one question well — can this identity open this object. It does not answer a second, different question: should this identity see this specific value inside it. A Medicare number in a CSV in a permitted folder is exactly as reachable as every ordinary field beside it, because the file is protected and the field is not.

That gap has always been closed by whoever builds the next consumer of the lake — a BI connector, a notebook, now an agent. An agent is not a slightly riskier version of the same problem. It changes who is asking. It is commonly provisioned with one standing service account. It composes its own queries against data it may misread. And nothing in the lake remembers what a given field actually is, well enough to stop it.

IAM, bucket policies, Lake Formation and Unity Catalog permissions are real controls. They attach to the storage, not to the meaning of what is stored. Three consequences follow.

Each new consumer rebuilds the rules. Reconstruct them slightly differently, or forget a field, and that consumer sees something the last one did not.

The service account becomes the person. The account's access is the agent's access, regardless of who is asking.

Classification, where it exists, is usually a catalog entry. A catalog entry is documentation. It is not a control.

Even a correct bucket policy does not stop the next agent being granted more than it needs, because nothing in the lake itself remembers what any given field is.

Four ways this shows up once the consumer is an agent:

  • A broad grant gets reused for every question, including the question that should never have reached that field.
  • An agent connected straight to the lake can reference a table or column that does not mean what it thinks it means, and nothing structural stops the query.
  • Every source added to the lake adds to what the agent must hold in mind just to find the right table. Past a point that context does not fit in the model's window, and it starts guessing.
  • Nobody owns the decision "should this request see this." The catalog describes it. The query does not consult the description.

How protection has to work​

Three rules, applied once, to the data.

Classify the data, not the connector. Attach sensitivity to the fact itself, so every future consumer inherits it. The alternative is reconstructing it, inconsistently, for each new tool — and the next tool is an agent.

Compute access from the real person, not the service account. Whoever is asking — a person, or an agent acting for them — should see exactly what that person is entitled to see through any other channel.

Never let the agent touch the database directly. The agent proposes what it wants to know. A governed, deterministic layer decides whether that is a real, permitted question before anything runs.

A person who is denied access notices and asks someone. An agent that is denied access should receive a masked value and carry on. The protection cannot depend on the agent, or on whoever built it, remembering to ask permission first.

Where CryspIQ® fits​

Security classification is carried on the fact type, alongside the business definition, using Microsoft Entra ID security groups and column-level Contextual Security, enforced with Microsoft SQL Server Dynamic Data Masking. Deny is the default: no group has access until it is explicitly granted, and anyone without it sees a masked value.

Lumen, the AI layer in CryspIQ®, computes authorisation from the real user's identity, not from a shared bot account. That holds whether the question comes from inside CryspIQ® or through Microsoft Copilot, ChatGPT Enterprise, Claude or another assistant. Someone asking through Teams sees what they would see asking directly.

Lumen never writes SQL. It emits a plan that references only identifiers already in the governed model. The plan is validated before anything runs, and a deterministic engine generates the query. A hallucinated field cannot reach the database. The model never touches table names, column names or literal quoting.

The schema stays the same whether three sources are mapped or three hundred, so the context an agent reasons over stays constant. It does not grow, source by source, until it no longer fits in a model's window.

The longer account of what has to be true before an agent is trusted with real work is AI agents in the enterprise. The incident itself, and why authorisation has to travel with the request, is covered in Does your AI agent know what it's allowed to see?

What this claims​

This is a narrower claim than "CryspIQ® would have stopped that breach." We do not know enough about the government system to say that, and anyone who tells you they do is guessing.

The claim you can test: an agent should never end up with more access than the person it is acting for. That has to be true by construction. Once the consumer is an agent, a policy someone remembers to apply will not hold.

The organisations that trust an agent with real work will be the ones whose data carries its own permission wherever it is read. If you cannot answer "what does this agent see that the person it is acting for would not?", the agent has already been trusted further than you have verified.

The PDF is AI Agents on Data Lakes, September 2026.

Related reading