Authorization moves to the data

Third and final article in the agentic security series. The first: the AI agent as a privileged account. The second: the lethal trifecta and the fire triangle.

An uncomfortable conclusion follows from the first two pieces in this series. The agent is a privileged account that does not behave like the accounts we know how to govern, and defence against prompt injection cannot be probabilistic. If you cannot guarantee how the agent will behave, only one conclusion follows: stop defending behaviour and defend the data.

The control is in the wrong place

In the architecture almost everyone is building, authorisation lives in the application and in the agent's token. It is the agent — or the tool it calls — that decides whether a piece of information may be read and to whom it may be shown. With two agents and five tools this looks manageable. Then the tenth agent and the thirtieth tool arrive, and the places where the control must be written, tested and maintained become the product of those two numbers. Every new tool is a new perimeter to defend, and one badly configured tool is enough to make all the others irrelevant.

The data, by contrast, is singular. It lives in a limited number of places: a few databases, a data warehouse, an object store, the ERP. Moving enforcement there means writing the rule once and seeing it applied to whoever queries — human, application, agent, today and in six months, including that integration nobody remembered leaving switched on.

What data-centric means in practice

This is not an abstract concept: these are controls production databases have had for years, and that almost nobody has extended to agents.

Row-level security — the database filters rows before the query returns anything. The agent querying the CRM on behalf of a sales rep sees that rep's customers: not because we instructed it to behave, but because the other rows do not exist in the response.
Column-level masking — sensitive fields come back redacted even inside a legitimate query. The agent computing order statistics receives revenue figures, not bank details and not tax codes.
Tokenisation and pseudonymisation — the direct identifier is replaced by a meaningless reference; re-identification requires a separate, logged step the agent has no reason to be able to perform.
ABAC — the access decision does not rest on a static role but on the attributes at play. NIST defines it as evaluating attributes of the subject, the object, the requested operation and — where relevant — environmental conditions against a policy. For an agent these are exactly the right questions: on whose behalf is it acting, on which data, to do what, from where.

The difference from guardrails is sharp and worth stating explicitly: the agent does not choose not to look — it cannot see. If a prompt injection convinces it to exfiltrate customer data, it exfiltrates the rows it was entitled to. The incident remains, but the blast radius is the one we decided on paper, not the one the attacker decided.

Propagated identity, not a service account

All of this works on one condition: that the data knows on whose behalf it is answering. This is where most agentic deployments fall down today. The agent connects to the database with a single, often generous, service account, and from that point per-user control is over: whatever reaches the end of the chain arrives with the same all-powerful identity.

The alternative exists and is standard: the identity of the user who originated the request is propagated along the chain — this is the OAuth 2.0 token exchange mechanism (RFC 8693) — and the agent cannot exceed that user's permissions. This is not whitepaper theory: Identity & Privilege Abuse is the third entry in the OWASP Top 10 for Agentic Applications 2026, and OWASP's own recommendation is to define per-tool profiles restricting permissions, data access and functionality to the minimum necessary. It is worth noting that this is the same principle we met when discussing the agent as a privileged account, applied one level lower: not to the agent's badge, but to the lock on the door.

The GDPR was already asking for this

Anyone working in data protection will recognise the argument: it is not a novelty of the agentic era, it is Article 5(1)(c) GDPR — data processed must be adequate, relevant and limited to what is necessary — and Article 25, data protection by design and by default.

An agent that connects with an all-powerful service account and receives the entire customer table in order to answer a question about a single order breaches minimisation, regardless of how it then behaves. Masking special-category fields and row-level security are not extra compliance layered on top of the project: they are the technical measure Article 25 asks for, applied where it can be verified. In the language of Article 32, pseudonymisation is named explicitly among the appropriate measures. Getting data-level controls right is not two jobs: it is one job that pays off for both security and accountability.

Five moves for Monday morning

Inventory: which datastores the agents touch, with which credentials. In most cases the list is longer than anyone remembers.
Row-level security enabled on agentic datastores, not only on those with human users in front of them.
Masking by default on direct identifiers and special categories (Art. 9): unlock the field when it is genuinely needed, not the other way round.
No shared service accounts between agents: propagate the user's identity, or at least give each agent its own identity and access profile.
Audit at the data level: which agent read what, on whose behalf, when. It is the only trail that holds up if an incident ever has to be reconstructed.

The three lessons of the series

Closing the circle: the AI agent is a privileged account, and as such must be identified, authorised and revoked. Agentic risk reads as a triangle — private data, untrusted content, outbound channel — and the defence is to break one side. And when the agent's behaviour cannot be guaranteed, permission must live in the data.

The common thread is that none of the three is a measure on the model. All three are measures on the architecture, verifiable on paper, independent of whichever LLM sits underneath in six months. That is good news: it means agentic security does not require chasing the state of the art in AI, but applying well the things we already know how to do.