The previous article in this series argued that the application layer has always been the real control layer for enterprise data — and that agents bypass it entirely. This article examines one of the most significant consequences of that bypass: the loss of authorisation control over what users can do and, perhaps more critically, what they can see.
This is not primarily a security argument, though security is implicated. It is an argument about the fundamental mechanics of how data access has always been governed — and why those mechanics fail silently when agents enter the picture.
The Application Knows Who You Are
Every enterprise application implements authorisation. Not just authentication — not just "are you allowed in" — but a continuous, contextual set of rules governing what each user can do and what data they can see.
There is an older version of this problem that I remember from the early client-server period. In the green-screen world, user identity was usually built tightly into the terminal application. It was not perfect, but the system had a clear idea of which operator was using which function.
The move to Visual Basic front ends changed that. These were Windows 3.1 desktops, often before network logins were a reliable part of the environment. If someone could sit at a PC and start the application, tying the action back to a real individual was much harder than it sounds now. Physical access to the machine did far too much of the security work.
Modern authentication has improved that enormously. But the underlying lesson still matters: if identity is only strong at the application layer, then anything operating behind that layer can collapse back into a shared technical account. The database may record that a service user queried or changed data, but that is not the same as knowing which person caused it, whether they were entitled to do so, and why the action happened.
A sales representative sees their own accounts and opportunities, not the whole customer base. A clinician sees their own patients' records. A regional manager sees their region's performance, not the company's. A payroll administrator can see salary data; almost nobody else can. These restrictions are not incidental features — they are fundamental to how the application functions correctly and safely.
In almost every case, these restrictions are implemented in the application layer. The application constructs queries that reflect the user's scope. It filters results before they are displayed. It withholds fields that the user has no business seeing. The database, for its part, returns whatever it is asked for. It has no independent knowledge of what any given user should or should not see. It trusts the application to ask the right questions.
Analytic and business intelligence tools follow the same pattern. Most modern BI platforms implement their own row-level security and data access models — but these are embedded in the tool, governed by the tool, and enforced by the tool. They work reliably within that environment. Step outside it, and they offer no protection at all.
The pattern is consistent across applications, across tooling, across the entire data access landscape: authorisation controls live in the access layer. The data layer enforces almost nothing.
The Agent Does Not Know the Rules
An agent operating autonomously has no knowledge of these rules. It was not built with your application's authorisation model in mind. It does not know that this user should only see their region, or that that field should never be exposed to anyone below director level, or that these records are restricted pending a legal hold.
It will ask the database for what it needs to complete its task. The database will answer. The filters that would have been applied by the application will not be applied, because the application is not in the loop.
The result is not a dramatic breach in the conventional sense. There may be no attacker, no exploit, no malicious intent. The agent may be doing exactly what it was asked to do. But the data it accesses — and potentially acts upon, summarises, or passes to another system — may be far beyond what the originating user was ever entitled to see. The absence of restriction is the vulnerability, and it was never visible because the restriction was never in the database.
The Stakes Are Not Uniform
Not all data carries the same consequences when access controls fail. It is worth being direct about the categories where the stakes are highest.
Commercially sensitive data presents a particular exposure because it is typically governed entirely by internal policy, not external regulation. Pricing models, margin structures, contract terms, strategic plans, acquisition targets — access to this data is controlled because the organisation chose to control it, enforced through application logic that reflects those choices. There is no external framework compelling the database to protect it. An agent that can query freely across the data estate may assemble a picture that no individual user was ever intended to have — not by accessing any single restricted record, but by combining data that was never meant to be seen together.
Regulated data raises the stakes from commercial damage to legal liability. Financial data governed by SOX, health information under HIPAA, personal data under GDPR — in each case, the regulatory framework imposes obligations not just to protect the data but to demonstrate that it was protected. The application layer was the mechanism through which compliance was implemented and evidenced. An agent that bypasses it does not just create an access risk; it may place the organisation in breach of its compliance obligations, with no audit trail capable of demonstrating otherwise.
Highly sensitive personal data warrants separate mention because the regulatory and ethical consequences of inappropriate access are severe and asymmetric. The special categories recognised under GDPR — health data, biometric data, racial or ethnic origin, political opinions, sexual orientation, and others — attract the highest levels of scrutiny and the most significant penalties. The burden of demonstrating lawful access is high. An agent that touches this data without a clear, auditable, user-level justification is not just a compliance risk; it is a harm risk, with consequences that extend well beyond the organisation.
The Audit Trail Proves Nothing
There is a further problem that compounds all of the above. When an agent accesses data through a service account or API credential — as is typical — the database audit log records that access against that credential. It does not record the end user on whose behalf the agent was acting. It does not record what the agent did with the data. It does not record whether the access was within the scope of what the user was entitled to see.
An audit trail that cannot answer these questions is not an audit trail in any meaningful sense. It is a log of connections and queries, which is useful for diagnosing technical problems but largely useless for demonstrating compliance, investigating incidents, or answering the question that regulators and data subjects will ask: who accessed this data, why, and were they entitled to?
The application always knew the answers to those questions. It encoded them in the queries it constructed and the filters it applied. That knowledge does not transfer automatically to an agent operating in its place.
The Database Was Never the Last Line of Defence — But Now It Needs to Be
The controls described in this article were not placed in the application layer through negligence or oversight. They were placed there deliberately, because the application was the right place for logic that was contextual, user-specific, and closely tied to the application's own data model. The database was never designed to be the last line of defence, because it was never expected to need to be.
That expectation is no longer safe. When agents can access data directly, bypassing the access layer entirely, the question of where authorisation is enforced becomes urgent. The database cannot continue to assume that someone upstream has already applied the appropriate filters. In an agentic world, there may be nobody upstream.
What that means for database architecture — for identity models, for access control, for audit infrastructure — is the subject of subsequent articles in this series. The starting point is recognising that the rules which governed data access for decades were written in application code, and that code is no longer guaranteed to be in the room.
Top comments (0)