The Authorization Layer

An employee used to find data, request it, wait days, then pull it down and work on it. Now they ask a question, and an AI agent does the rest — hundreds of queries, in seconds, all of them in their name. Every one is an access decision, and almost no enterprise has a single place to make it.

We have rebuilt Immuta as a data authorization layer. That meant changing the architecture, reordering the roadmap, and giving up assumptions we had held since the beginning. This piece explains why.

For a decade we built access control inside the data platform. Author a policy once, enforce it natively wherever the data sits, prove it afterwards. That model assumed a person at the other end of the request — someone who knew what they wanted, asked for it, and waited. Very little of that still holds. The requests now come from agents, arrive by the thousand, and are composed at runtime by something that has never opened your catalog.

We did not expect that shift to arrive this quickly, and it changed both what we built and the order we built it in. What follows is the reasoning behind the change, the four capabilities we are launching into it, and the honest cost of adopting them.

The short version: authorization stops being a feature of each data platform and becomes a layer across all of them.

Part one: What changed

The way people get data is being replaced

Not improved. Replaced. For thirty years the answer to how do I get that data has had the same shape: find it, ask for it, wait, receive it, work on it. The tooling around each step got better — catalogs, ticketing systems, self-service portals — but the shape never changed, and neither did the assumption underneath it. A person knows what they want before they ask for it.

That assumption is now false, and it went false faster than any governance program was built to move.

The old loop had eight steps. Every one of them was a place where a person exercised judgment, which made it a place governance could attach itself.

This is not a productivity story. The harness — Claude, ChatGPT, Copilot, whichever wins the seat — is becoming the surface the enterprise operates from. It is where questions get asked, where work gets initiated, where decisions get staged. The honest description of most knowledge work within a few years will be: a person talks to a harness, and the harness talks to everything else.

That relocates what matters. The data estate was the strategic asset of the last decade; it becomes infrastructure. What separates two companies with the same platforms is no longer what they have stored. It is what their agents can reach, how fast they can reach it, and whether anyone can prove afterwards that they were allowed to.

Nobody is going to browse a catalog again, and that matters more than it sounds. The entire request-access workflow was built on the assumption that a person had already identified the dataset they wanted. By the time you know precisely what you need, you have done most of the work. In the new loop, that step never happens at all — which means the place where governance used to attach itself no longer exists.

An agent has parameters, not a conscience

This is the part that changes the security model rather than just the user experience.

An agent does not pause to wonder whether it ought to be looking at something. It has an objective and a set of tools, and it will find the best available path to that objective. That is the entire value proposition. It is also why a boundary written into a prompt is not a boundary. Models cannot reliably separate instruction from context, so injection is not a risk to be driven to zero — it is a property of the medium. Anything that must hold regardless of what the model was told has to be enforced underneath the model, at the data itself.

And agents do not work alone for long. One employee asks one question. Her agent makes forty calls to answer it. Its sub-agents make four hundred.

Part two: Why the machinery breaks

Speed, scale and risk break at the same time

Multiply access decisions by three orders of magnitude and the machinery underneath them does not degrade gracefully. It gives way in three places at once, and they are the three things every access process was designed around.

Processes built for the dashboard era are not slightly behind. They are the wrong shape.

Put it concretely. A person discovers the data, opens a ticket, waits for an administrator, receives the grant and asks their question two or three days later. An agent identifies the gap, has it evaluated, receives scoped access and runs the query inside the same execution cycle. Forty-eight hours against a few seconds. That is not a delta you close by staffing the queue differently.

If your agent has to wait for somebody to click Approve in a ticketing system, your AI program is already over. It just has not been told yet.

The other failure is quieter and worse. The fastest way to unblock an agent is to hand it a broad service account, which is exactly what most pilots did. Everything then works, right up until the review, when the audit log names the account rather than the person, and nobody can say what was actually seen or why.

Authentication is solved. Authorization is not.

The reasonable instinct at this point is to ask which system you already own should absorb the problem. It is worth walking through why none of them can.

Every large enterprise already knows who is asking — Okta, Entra, Ping, and increasingly an agent identity layer above them. Most also know what their data is and which parts of it are sensitive. Chief data officers have done that work: cataloged the estate, classified it, tagged it. It is unglamorous, it took years, and it is considerably further along than it usually gets credit for.

Neither of those things decides what a given request may return.

Today that decision gets made five different ways at once — grants, RBAC, ABAC, IAM policies, OAuth scopes. Five mechanisms, five teams, one rule rewritten in each dialect, and within a quarter they no longer agree with one another. One customer was maintaining twenty thousand hand-written policies across that sprawl before they stopped. Nobody in that position can answer the auditor's real question, which is not what is your policy but who could see this last quarter.

You cannot fix this by writing more rules, because you cannot pre-write a rule for a question nobody has asked yet. What is missing is not policy. It is a place for the decision to be made.

Authorization stops being a feature of each platform and becomes a layer across all of them.

Part three: The bar

What makes an enterprise agentic-ready

An agentic-ready enterprise is not one that has deployed a harness. It is one whose access model can survive a harness being used properly. Seven things have to be true, and they have to be true together — because any one of them missing forces the same two bad choices: over-permission the agents, or block them.

01: Every actor is named, and the audit can tell them apart

An agent working for a person is two identities, not one. Shared service accounts and user impersonation both collapse that into one, and once collapsed it cannot be recovered — no review will ever establish who triggered what. Readiness starts with being able to say, of any row that was returned, which human it was returned for and which agent fetched it.

The Test: Can you tell a query your analyst ran from one her agent ran on her behalf?

02: Every data source is in scope, and enforced where it lives

An agent reaches for whatever answers the question: the lakehouse, an object store, a dashboard, a SaaS application, an internal API. Coverage that stops at the warehouse boundary governs a shrinking fraction of what actually gets touched. And coverage bought by routing queries through a proxy trades one problem for two, adding latency to every request and a second copy of your data to defend.

The Test: Name a system in your estate an agent could reach that your policy model does not cover.

03: Permissions resolve at the context layer, at the moment of the request

Precomputed access answers what an identity may reach. That question was tractable when a hundred analysts asked predictable questions of a fixed set of tables. It is not tractable when the question itself is generated at runtime by a model that chooses its own path. You cannot pre-provision for a question nobody has asked. The decision has to weigh the actor, the data, the purpose and the moment together — and return in under a second, because it is happening inside somebody's task.

The Test: How long does it take to answer a request that no existing role covers?

04: Purpose is an input to the decision, not a field in a form

Two identical queries can be entirely different acts. Pulling customer records to investigate suspected fraud and pulling the same records to build a marketing list are indistinguishable in SQL. If purpose exists only as free text in a justification box, it governs nothing and proves nothing. Declared intent has to reach the policy engine and change what comes back.

The Test: Can the same person, querying the same table, get different results depending on the task they declared?

05: Authority only narrows, and nothing outlives the task

Delegation should be lossy by construction. Each hop — person to agent, agent to sub-agent — gets a smaller slice than the one above it, never an equal or larger one. And access created for a task should disappear with it, without anyone remembering to revoke it. Standing privilege was a tolerable risk when it belonged to people who go home at night. It is not one when it belongs to processes that run continuously and can be steered by text they read.

The Test: What would an attacker inherit by compromising an agent in your environment today?

06: Exceptions resolve in-band, at the speed of the work

Most access decisions are routine and should never reach a person. The ones that genuinely need judgment should arrive with the question, the classification and the requester's context already attached, and should carry an expiry. Any architecture where a missing permission becomes a ticket has a human-speed component sitting inside a machine-speed loop, and that component sets the pace of everything around it.

The Test: When an agent hits a permission it does not have, what happens in the next five seconds?

07: Every determination is evidence at the moment it is made

Reconstructing who saw what from platform query logs was always a compromise; at agentic volumes it stops working. The decision itself is the record: which actor, acting for whom, under what policy and purpose, against what data, with what outcome and what masking applied. Written as it happens, an audit is a query. Assembled afterwards, it is a project with gaps in it.

The Test: How long would it take to answer what a given agent could see last quarter?

Most organizations can satisfy two or three of these today. The distance between three and seven is the distance between a pilot and production.

Part four: What we built‍

‍Era three arrived early

Immuta has been through this twice before. In 2015 the product was data security: a policy engine letting governance teams author fine-grained rules and enforce them natively across an estate. Around 2020 it became data provisioning as well — request workflows, routed automatically, so getting access stopped meaning filing a ticket and waiting on a queue.

Neither era replaced the one before it. Each added an actor. Governors, then approvers and the requests they handle, and the same policy engine carried all of it.

Era three is agentic governance, and the honest part of this launch is the timeline. It arrived considerably faster than we planned for.

We expected a gradual handover — agents appearing alongside human consumers over several years, governance adapting at the pace enterprises usually adapt. That is not what happened. The frontier labs have been shipping faster than any roadmap cycle can absorb, ours included. Customers put harnesses in front of production data before the architecture for it existed. We have been adjusting in real time: reprioritizing the roadmap mid-year, and in some cases rethinking assumptions we had held since the first era.

What follows is the result. Four capabilities, each answering one of the principles above.

Coverage: Universal Access Controls

If your policy model only covers the data platform, it covers the shrinking part of the problem. Universal Access Controls extend the same model to anything granted through an identity-provider group. Register the object, map it to a group of its own, tag it, and an ordinary attribute-based subscription policy governs it from then on — a Power BI dashboard, create-table rights on a schema, an internal application, a data API.

Membership is added and removed as policy grants and revokes, for people, service principals and agents alike. Identity governance tools can already tell you who is in a group; none of them can tell your governance team what that group reaches. This closes that gap without moving anything.

Identity: Agentic access, on behalf of

There are three ways to give an agent data and only one preserves least privilege. A shared service account is coarse by construction and destroys attribution. Impersonation is worse: the agent inherits everything the person holds, including administrative privilege, which turns any prompt injection into a confused-deputy problem with real consequences.

The third way is to decide at runtime. We evaluate the intersection of the human's authority, the agent's permitted capabilities and the task at hand, then vend a short-lived role natively inside your own platform, named for both parties so the audit can always separate them. The agent connects with it, runs the query, and the role is dropped when the task ends or the TTL expires. Nobody impersonates anybody, and nothing survives the task.

Purpose: Intents

Who is asking has never been enough on its own. The same analyst working two different tasks should not see the same thing, and until now the only vocabulary for expressing that was identity — which is why organizations ended up with a role per exception and thousands of groups nobody dares delete.

An Intent is a declared business task. When a user acts under one, birthright access pauses and only the data belonging to that task is visible — genuinely hidden, not merely unqueryable. Policies resolve differently because the actor now carries the task's attributes. Every query is tied to the declared Intent in the audit record. That is the difference between logging access and constraining it, and it is the difference regulators have begun asking about.

The same mechanism is how an agent gets isolated to its work. Governed people act under Intents; agents act on behalf of people, under Intents. Purpose becomes something the system enforces rather than something recorded in a box nobody reads.

Workflow: Requests inside the harness

The least glamorous capability here carries the most weight. Requesting access has to stop being an application a person visits.

When an agent has a query ready, it should be able to ask whether the person it works for is missing anything — an entire table, a single column, a row filter exception — and if so, file the request itself, in the moment, with the question attached. A review flow evaluates it right there and returns one of three answers.

Over time the pattern of human decisions becomes the raw material for the rules, and the share of requests needing a person falls.

The honest cost

This only works if access decisions move off static database roles and onto policy. If your model is a role per question, none of the above will save you, because you will be writing roles for questions nobody has thought to ask. That migration is real work and we are not going to pretend otherwise.

What we can say is where it lands. One manufacturer collapsed twenty thousand hand-maintained policies into twenty attribute-based ones and cut time-to-data from five days to two minutes. Another replaced more than eighteen thousand legacy permissions with six policies. Those ratios are not a matter of cleverness. Most of what sits in a mature access estate is the accumulated residue of exceptions that were never expressible any other way.

The second cost is a change in where evidence comes from. Reconstructing an audit trail out of your data platform's query history after the fact was always a workaround — laggy, incomplete, and it made the platform the source of truth for something the authorization layer should own. When the decision point sits in the path of the request, the evidence is written at the moment of the decision. Compliance becomes a query rather than a project.

Part five: What It Means

Where the data lives stops being the question

At the start of this piece we claimed the data estate becomes infrastructure, and that what separates two companies with the same platforms is what their agents can reach. That is the part worth spelling out, because it runs against how most enterprises have spent the last decade.

For five years the hard question in enterprise data was where it should live. Get it out of the basement and into a cloud platform — Databricks, Snowflake, BigQuery, Starburst, Redshift, take your pick. Stand up the lakehouse, retire the Hadoop cluster. Enormous capital and organizational will went into answering that question, and the answers are now in production.

That work was not wasted, and the platforms it produced are where enforcement still has to happen. But it is worth being honest about part of why it was done. Consolidation was, among other things, an attempt to make data governable by making it co-located. Policy could only follow data so far, so data was brought to where policy could reach it.

That constraint is what an authorization layer removes. If an agent can reach any system holding an answer, and one layer decides what every one of those requests may return, then the physical location of a given table becomes an implementation detail rather than a governance decision.

Enterprises will care less about where their data lives and more about whether their data layer can be safely exposed.

Exposed to employees, to the harnesses they work through, to the agents those harnesses dispatch, and to whatever comes after them. The advantage goes to whoever can say yes fastest without losing the ability to prove they were right to. That is a very different capability from owning the largest warehouse, and it is not one you can acquire at the last minute.

Next: authorization intelligence

Era three has its own arc, and we are at the beginning of it. Deciding well is the first requirement. Understanding the decisions is the next, and it is where our attention turns in November.

When a layer is making millions of determinations a day, the interesting questions change. Not what does the policy say, but: what precedent already exists for this kind of request, where is entitlement drifting from what anyone intended, which grants have gone unused for ninety days, which temporary approvals are quietly still live, and which classes of decision have gone the same way often enough that a person no longer needs to see them.

One thing does not move. The authority stays human. Only the execution becomes autonomous.