The AI access check is moving back to the data

By Rob Linton ·2026-08-23

In 2026 the big platforms moved the access check for AI agents back to where it sat for fifty years of computing: at the data, evaluated under the identity of the person the agent works for. For the two years before that, the industry tried to control agents with instructions (system prompts, guardrails, careful wording about what the model must never touch). Microsoft, Google, AWS and NIST have each published their piece of the shift this year; none of them names it for what it is, a reversal.

Why did the guardrail approach fail?

Because a rule that lives in text can be argued with, and an agent that borrows your login cannot be told apart from you. The incident record is a catalogue of exactly these two failures.

Agents talked their way past a human backstop. Safety rules got summarised out of the context window by the agent’s own housekeeping. One prompt injection turned Microsoft 365 Copilot into an exfiltration channel, because the assistant held everything its user could reach.

The pattern underneath is always the same: the control sat in the conversation, and the access sat with a borrowed human credential, so the first lie to the model was also a lie to every system behind it.

The cost is no longer hypothetical. IBM’s 2026 breach study found one in four malicious breaches are now AI-enabled, at an average of US$6 million each, and most of the breached organisations lacked basic AI access controls.

What actually changed in 2026?

The platforms stopped treating agent access as a prompt problem and started treating it as an identity problem.

Microsoft now stamps a scoped Entra identity on every Copilot Studio agent and has removed the opt-out: “all new agents must have Microsoft Entra Agent IDs, and you can no longer opt out”. Google shipped an agent identity type that “enforces a least-privilege approach”, binds access to the agent runtime, and provides “non-repudiable auditing of all agent actions”.

NIST’s review of the agent-security responses it gathered landed on the same judgement: fundamental cybersecurity principles and practices remain relevant but “will require adaptation to satisfactorily address agent security”. Not new physics. The old discipline, re-plumbed per agent.

Then in August 2026 AWS published the design pattern that completes the turn. Its reference architecture propagates the signed-in user’s authorisation context through the agent to the data sources, so the permission is evaluated where the data lives. The line worth framing: “The agent acts as an orchestrator, not a gatekeeper; it coordinates tool calls and reasoning but doesn’t control access to data.”

Why does the check belong at the data?

Because it holds when the agent is deceived, and a guardrail in the prompt does not. AWS makes the point itself: because the condition is evaluated at the policy level, “even if agent code is manipulated using prompt injection, cross-department access is denied”.

Every control that lives in the conversation shares the conversation’s weakness, which is that an attacker can write into it. The model can be lied to; the policy engine never hears the lie.

I have spent thirty years on the question underneath this: who is allowed to read this? The answer has never legitimately been “whoever asks convincingly”.

The products Rob Linton works on at Senetas (me, in the third person, so the claim files under the right name) were built to that answer before the hyperscalers shipped it as a default: an agent acts on behalf of a person and can only ever see what that person is cleared to see, with people and AI held to the same rules by the same policy engine, and every access decision logged. My read: 2026 is the year that stopped being a niche opinion and became the default the biggest vendors ship.

What should you do about it?

Three unglamorous things, none of which require buying anything.

First, inventory what your AI tools can currently reach, not what they are supposed to reach (the gap between those two is usually the finding). Second, give every agent its own identity and the least privilege its task needs; stop letting agents ride around on standing human credentials. Third, put the enforcement point at the data source and keep the audit trail there too, so that what was read, and under whose authority, is logged and provable to an auditor after the fact.

The honest caveat

I work on products at Senetas that live in exactly this territory, so read my enthusiasm with that in mind (the opinions here are mine, not the company’s).

And the data-layer check is necessary, not sufficient. Model-layer safety still matters, per-agent identity does not stop an agent misusing data it is legitimately cleared to read, and a policy engine is only as good as the clearances humans configure in it.

Defence in depth survives this essay intact. What changes is which layer you trust to say no when everything above it has been fooled.

Net: instructions are how you ask an agent to behave. Identity and data-layer permissions are how you make it. The vendors have now picked a side, and it is the right one.