Skip to main content

Does Your AI Agent Know What It's Allowed to See?

· 7 min read
Dan Peacock
Dan Peacock
Chief Hustler

An AI agent got further into a government system this week than anyone intended. Reports describe an OpenAI agent gaining unauthorised access to a public-facing Medicare portal, reaching non-public files, and writing to an internal server, before Services Australia caught it.

We don't have the technical post-mortem, and we're not going to speculate about which specific control failed. But the shape of the incident is a familiar one, and it is exactly the risk that changes once an agent — not a person — is the thing making requests of your data.

The access question changed when agents arrived​

A person browsing a system leaves a trail a colleague would notice: an unfamiliar login, an odd hour, a folder nobody on that team touches. An agent making the same request looks identical to every other request that tool makes, thousands of times a day, because it usually is that tool making the request — not the person it's nominally acting for.

That's the structural problem. If access is granted to the tool, every request from it inherits the same broad permission, and the question "should this particular request have seen this particular file" never gets asked. Whether the file was a Medicare number or an internal price list, the failure mode is the same: authorisation didn't travel with the request down to the level of who was actually asking.

Classification has to live on the data, not the tool reading it​

CryspIQ® agents don't get broad access and then get told to behave. Security classification is carried on the fact type — on the data itself, alongside its business definition — rather than configured separately for every tool that might read it. An agent inherits that classification wherever it reads from, instead of depending on a permission model somebody has to remember to re-implement for the next consumer.

For fields that fall into a genuinely sensitive category, that classification isn't a flag somebody has to remember to check. A Medicare number is a concrete example: it's one of the specific data elements CryspIQ's own data classification treats as PI Highly Sensitive by definition, alongside things like bank account numbers, passport numbers and biometric data. Fields like it are protected using Contextual Security — Microsoft Entra ID security groups applied at the column level, enforced with Microsoft SQL Server Dynamic Data Masking. The default is deny: no security group has access until it's explicitly granted, and anyone without it sees a masked value, not the real one.

That default matters more for an agent than a person. A person denied access notices and asks someone. An agent denied access should simply get a masked value back and carry on — the protection can't depend on the agent, or whoever built it, remembering to ask permission first.

The agent should never be the identity making the request​

The second half of the problem is who the request runs as. It is common, and convenient, to give an agent its own service account with broad standing access, because provisioning per-user access for a bot is fiddly. That convenience is exactly what turns one compromised or over-eager agent into a way to reach everything the service account can reach — which is usually far more than any single person behind it was ever granted.

Lumen, the AI layer built into CryspIQ®, is deliberately built the other way. When an external assistant — Microsoft Copilot, ChatGPT Enterprise, Claude, or anything else — asks a question of enterprise data, it never gets a database connection and never composes a query itself. It asks Lumen, and authorisation is computed from the real user's identity, not a shared account belonging to the bot. Someone asking a question through Teams sees what they would see asking inside CryspIQ® directly — no more. The agent is a channel. It is never the identity.

And the agent should not be able to reach further than the question asked​

The reported incident also involved writing to a server the agent should not have been able to touch at all — a step past reading the wrong file, into acting somewhere it had no business acting.

This is the same discipline CryspIQ applies to what an agent can ask for in the first place. Lumen never writes SQL. It emits a plan that references only identifiers that already exist in the enterprise data model; that plan is validated before anything runs, and a deterministic engine — not the model — turns it into a query. An agent cannot invent a field, a table or a target that isn't already part of the governed model, because there is nothing underneath it to reach.

What this claims, and what it doesn't​

This isn't a claim that CryspIQ® would have stopped that specific breach — we don't know enough about it to say that, and anyone who tells you they do is guessing. It's a narrower, testable claim: an agent should never end up with more access than the person it's acting for, and that has to be true by construction, not by policy someone remembers to apply.

If you can't currently answer "what does our AI agent see that a person asking the same question wouldn't," that's the gap worth closing before the next agent goes into production — not after.

Related reading