Restoring Need-to-Know.
Need-to-know is the oldest rule in information security, and almost nobody is running it. Since 1976 the enterprise has decided data access in advance — writing down what each person is allowed before they ask for anything — because deciding one request at a time was impossible at human scale. This is how that compromise was made, why nobody undid it, and why AI makes it both untenable and, for the first time, fixable.
Chapter heading goes here.
Subhead goes here: one or two sentences that set up the chapter.
Ask a large enterprise a simple question. Who can see this table, and why?
Watch what happens. Somebody pulls entitlements out of the warehouse. Somebody else cross-references group membership in the identity provider and finds that two of the groups have names which no longer describe anything. A third person remembers that a masked copy of the table exists in a different schema, and that the copy has its own permissions. Someone goes looking for the ticket that granted an exception, finds it, and discovers it was closed in 2021 by an employee who has since left, with a justification field that reads as discussed. Four weeks later a spreadsheet arrives. It is accurate on the day it is delivered and wrong by the end of the week.
This is not incompetence, and it is not unusual. It is the predictable output of a model that has been running, largely unexamined, for fifty years.
The model is simple enough to state in one sentence: access is a durable property of an identity, decided in advance, and stored in the system that holds the data.
Everything the enterprise does about data access is an attempt to keep that sentence true at scale. Roles exist because it does not scale to thousands of people. Attributes exist because roles do not scale to thousands of roles. Access reviews exist because the sentence has no expiry date. Ticket queues exist because it has to be amended constantly. Masked copies exist because it cannot express a partial answer. None of these are mistakes. Each is a competent engineering response to a real constraint, and each one made the next problem harder.
For five decades the assumption mostly held, because three conditions were mostly true. There was a knowable population of people. There was a knowable set of systems. And there was a knowable set of questions, because software was written before it was run, and a question nobody had implemented could not be asked.
All three of those conditions ended inside the last thirty-six months.
What follows is how the model was built, why it held for so long, why every reasonable attempt to patch it compounded the underlying flaw, why no vendor in the market had an incentive to fix it, and why the arrival of AI agents does not strain the model but ends it. It closes with an argument about what has to exist instead. Our own interest in that argument is declared twice: once at the point in the history where we enter it, and again at the end.
If you read nothing else.
Access control was designed for a room with one computer in it.
Its formal machinery comes from military time-sharing systems in the early 1970s, and its enterprise vocabulary — grant, revoke, privilege — from a single 1976 paper on a database prototype at IBM. The assumptions embedded in that vocabulary are still running your bank.
Everything since has been a compression scheme for the same model.
Roles compressed a matrix that had grown too large. Attributes compressed roles that had grown too numerous. Both were real advances. Neither changed the unit being compressed, which was always a standing permission held by an identity.
The industry standardized the front door and walked away from the interior.
Authentication got protocols, a market and clear winners. Authorization got one serious attempt at the same treatment, and when it failed the decision was left inside every platform, in every platform's own dialect.
Purpose was the requirement no model could express.
From 2018 onward, regulators stopped asking who has access and started asking why this access, for what declared purpose, and was it the minimum necessary. Purpose is a property of a request, not of a person. There was nowhere in the architecture to put it, so enterprises answered a structural question with paperwork.
The workarounds became the architecture.
More roles, more copies, more tickets, more standing privilege, and an annual review that everyone involved understands to be theatre. Nobody designed this. Every organization built it, one locally rational decision at a time.
Agents break the last assumption standing.
You cannot write down in advance what a question will need, because the question does not exist until it is asked — and it is now being asked thousands of times an hour by things that are not people. That is not a scaling problem to absorb. It is the end of pre-decided access.
Eleven chapters.
This part is the diagnosis: how the enterprise ended up unable to say who may see what, or why, and what has to exist instead. Part two, Authorization Intelligence, is about proving it at scale. Part three, Autonomous Authorization, is about deciding it without a person in the loop. Neither makes sense before this one.
The model was built
for one room.
Before time-sharing the question did not exist. A computer ran one program for one organization, and the security model was the lock on the door.
Time-sharing created the problem. Once a single machine served many people at once, someone had to decide what each of them could reach, and the machine had to enforce it rather than a scheduler with a clipboard. Multics, begun in 1965, is where most of the vocabulary starts. By 1971 Butler Lampson had written the problem down formally as a matrix of subjects against objects with permitted operations in the cells. In 1972 a US Air Force study articulated the reference monitor: one component every access attempt must pass through, small enough to verify and impossible to bypass. In 1973 Bell and LaPadula published the model that would govern classified systems for a generation.
Two things about that founding period matter more than the models themselves.
The first is who paid for it. Almost all of the formal work came out of defense, where the sensitive thing is the document and the purpose of access is a given. If everyone in the building is cleared and working on the same war, you do not need to model why someone wants a file. You need to model how secret the file is. Access control was therefore born classifying objects rather than evaluating requests — an inheritance still visible in every tool that wants to tag your data and stop there.
The second is what happened when the theory met commercial databases. Codd had published the relational model in 1970, and by the mid-seventies IBM was building System R, the prototype that gave us SQL. In September 1976, Patricia Griffiths and Bradford Wade published its authorization mechanism. That paper is the origin of GRANT and REVOKE, and of nearly everything a database administrator does today.
It was excellent work, and it was correct for its constraints. One system. A few hundred users. A few thousand tables. Applications written before they were run, which meant the set of possible questions was fixed at compile time. Under those conditions, deciding access ahead of time and writing it into the catalog is not a compromise. It is the efficient answer.
Look at the word we chose. A grant is a gift. It is given once, and it persists until somebody takes it away.
THE VOCABULARY ENCODES THE ASSUMPTION
Nothing in that vocabulary has a place for how long, for what purpose, or under what circumstances. There is no verb for allow this one question. Fifty years later we are still trying to express temporary, purpose-bound, context-dependent permission in a language whose only primitives are a permanent gift and its withdrawal. A great deal of what enterprise data governance costs is the friction of that translation.
By 1985 the Orange Book had codified the defense worldview into a formal evaluation standard, and the commercial world had settled into the System R model. The foundation was poured. Everything after this is an extension.
Roles were
a compression algorithm.
The matrix worked until both of its dimensions grew. Every model since has been an attempt to compress it without changing what it contains.
By the early nineties the arithmetic had become impossible. Users multiplied, objects multiplied, and the matrix is their product. In October 1992 David Ferraiolo and Rick Kuhn presented role-based access control at the National Computer Security Conference, proposing an intermediate layer: assign permissions to roles, assign people to roles, and manage the two smaller relationships instead of the enormous one between them. Sandhu and colleagues formalized the family of models in 1996. It became an ANSI standard in 2004. It was a genuine and enormous success — NIST later assessed that its own RBAC research had saved industry well over a billion dollars.
Roles worked because they encoded a true observation about 1992: job function was a good predictor of data need, job functions were enumerable, and they changed slowly. A claims adjuster needed what claims adjusters needed. That was a sound bet for about fifteen years.
Then compliance arrived, and did something subtle and lasting.
HIPAA in 1996, Sarbanes-Oxley in 2002, Basel II shortly after — each required organizations to demonstrate control over who could see what. The model could not answer the question an auditor actually cares about, which is whether a given access was appropriate. So the industry substituted a question it could answer: whether the access had been approved. Proof of process replaced proof of correctness.
That substitution is why an audit is a document-gathering exercise instead of a query. It has been in place for twenty years and almost nobody notices it any more.
APPROVED, NOT APPROPRIATE
From it came the machinery every large enterprise now operates: certification campaigns, quarterly access reviews, attestation workflows, evidence binders. An entire discipline whose output is a record that somebody signed off, and whose relationship to whether the access was correct is assumed rather than demonstrated.
Meanwhile the compression kept failing upward. Roles proliferated, because the cheapest way to handle any exception is a new role. By 2014 NIST had published guidance on attribute-based access control: stop enumerating roles, and evaluate attributes of the subject, the object and the environment at the moment of access. One attribute-based policy can cover a class of users automatically, including users who did not exist when it was written, which removes per-person provisioning entirely. On paper it was the best answer anyone had produced in twenty years.
Where we enter this story.
A specification is not a product. Reading that guidance in 2014 told you what the model should do. It did not tell you how to make a warehouse honour it. To actually run attribute-based access control you had to stand up your own decision point, integrate it with every platform that held data, and express every policy as code. Which meant that the only people who could operate the best available access model were engineers.
That gap is worth stating precisely, because it is not a technical one. The people who own the rules are not engineers. Rules come from the general counsel, the privacy officer, the compliance lead, the data governance team — people who can tell you exactly which populations may see which fields under which conditions, and who have never written a line of SQL. Under ABAC as specified, those people could author nothing. They wrote requirements into documents, handed them to a platform team, and waited to learn whether what shipped matched what they meant. Usually nobody could say, because checking required reading code.
So the best access model available sat in reference architectures, widely admired and largely unimplemented.
ABAC, 2014
Immuta was founded in 2015 to close exactly that gap. The founding team came out of the US intelligence community, where the consequences of getting data access wrong are not hypothetical and the rules governing it are not simple — classification, compartment, nationality, purpose, and contractual restriction, all at once, on the same record. They had watched capable people fail to implement policies they could describe perfectly well in a sentence.
The premise was narrow. Let the people who own the policy write it themselves, in plain business terms, and have the system compile it into whatever each platform enforces natively. No code. No copies of the data. No provisioning per person. The rule leaves the lawyer's hands and arrives in the database as the database's own controls, and anyone can read back what it says.
It took about a year to get that working commercially, and the reason it kept working for a decade is that it was aimed at the operator rather than the algorithm. Every subsequent era of this story — request workflows, purpose, agents — has been an extension of that one premise, not a replacement for it.
But notice what even the best version of this still requires. Ours included. You must anticipate, in advance, the categories of data that each category of person might ever legitimately need. The compression ratio improved by orders of magnitude. The thing being compressed did not change. It was still a standing permission, decided before the question was asked.
We standardized
the front door.
One half of the problem got protocols, a market and clear winners. The other half got one serious attempt, and then silence.
Authentication is a solved problem, and it is worth remembering how recently that became true. SAML 2.0 arrived in 2005. OAuth 2.0 was published as an RFC in 2012, OpenID Connect the following year, SCIM alongside them for provisioning. Within a decade, proving who is asking became an interoperable, protocol-defined layer that any application could delegate to. A large market grew on top of it. Single sign-on went from an integration project to a checkbox. This was one of the great infrastructure wins of the century, and nobody should be nostalgic about what came before.
Authorization received exactly one attempt at the same treatment. XACML was ratified as an OASIS standard in February 2003, with a third major version in 2013. Architecturally, it was right. It separated the place policy is written from the place a decision is made from the place a decision is enforced — administration point, decision point, enforcement point. That decomposition is still the correct shape of the thing the enterprise needs. Anyone designing an authorization layer today is, knowingly or not, redrawing that diagram.
It did not take. The reasons are worth naming, because they explain why nobody tried again for fifteen years.
- It was verbose XML that developers refused to write, and the tooling never arrived to hide it.
- It was deliberately abstract, with no opinion about data. It could say deny, and had nothing to say about which columns to mask or which rows to withhold.
- Above all it had no enforcement path into the systems that hold the data. A decision point can return an answer, but something must make a warehouse return fewer rows. XACML never had a story for that, so enforcement remained whatever each application chose to implement.
The lesson generalizes well beyond one failed standard. A decision you cannot enforce inside the system holding the data is not a control. It is an opinion. Every subsequent attempt at a policy layer that sits beside the data rather than inside it has run into the same wall, and most of them are still running into it.
So authorization stayed exactly where it had been since 1976: local to each application and each database, written in that vendor's dialect, by whoever owned that system. The enterprise ended up with a front door governed by an international standard, and interior walls governed by nothing at all.
The data consolidated.
The controls multiplied.
The cloud era solved the hard part of data architecture, and made the access problem five times worse in exactly the way you would predict.
Hadoop and cloud object storage both arrived in 2006. Cloud warehouses followed, then lakehouses. Within a decade, data that had lived in hundreds of application databases was consolidating into a handful of platforms, which was a straightforward architectural victory. At the same time storage became cheap enough that deleting anything cost more attention than keeping it, so nothing was deleted and everything was copied.
Every one of those platforms shipped its own access control, because it had to. The Hadoop ecosystem got one policy framework, then another. Warehouses implemented role hierarchies with their own grant semantics. Object storage got identity policies written in a completely different idiom. Internal APIs got scopes. Five mechanisms, five vocabularies, five owning teams, none of whom were wrong.
The consequence was that a single business rule — EU customer identifiers are visible only to EU-based staff handling that customer's account — now had to be written five times, in five languages, by five groups of people who did not attend the same meetings. Within a quarter the five versions disagreed. Not through carelessness; through the ordinary drift of five independent codebases with no shared source of truth.
When you cannot express a rule about the data, you produce data that matches the rule instead.
THE ORIGIN OF COPY SPRAWL
And so the second great workaround appeared. A masked copy for the offshore team. An aggregated copy for the executive dashboard. A de-identified extract for the research group. A pseudonymized version for the vendor. Each copy was a policy decision frozen into a table, and each began drifting immediately — from the source data, and from the reason anyone made it. Ask a data platform team today how many copies of their customer table exist and why, and you will get an estimate rather than an answer.
Two structural facts came out of this decade and both are still true. Data location consolidated and policy did not. And the organization lost the ability to state its own rules in one place, which means it lost the ability to check them.
FOUNDATIONS · THE MODEL IS SET
COMPRESSION · SCALING THE SAME MODEL
DIVERGENCE · IDENTITY WINS, AUTHORIZATION FRAGMENTS
THE BREAK · THE QUESTION BECOMES THE UNIT
Read down the right-hand column. Not one of these was a mistake at the time. The compounding is the story.
Purpose was the requirement
nobody could express.
In 2018 the law began asking a question about the request. The architecture could only answer questions about the person.
The General Data Protection Regulation came into force on 25 May 2018, and with it two principles no access control model on earth could represent. Purpose limitation: personal data is collected and used for specified, explicit purposes, and not repurposed incompatibly. Data minimization: use the least data adequate for that purpose. California followed. Sector rules had said versions of this for years — HIPAA's minimum necessary standard is from the nineties — but 2018 is when it acquired teeth and a global scope.
Strip the legal language away and both principles are need-to-know, written into statute. The regulators were not asking for a new control. They were asking the enterprise to run the oldest one it already claimed to believe in, and to be able to show its work.
Consider what purpose limitation demands of a control system. The same analyst, querying the same table, with the same job title, on the same afternoon, is compliant if she is investigating a suspected fraud and non-compliant if she is enriching a marketing list. The identity is identical. The data is identical. The permission is identical. The only difference is why, and why is a property of the request.
There is nowhere to put it. Not in a role, which describes a person. Not in a grant, which describes a relationship between a person and an object. Not in an attribute of the subject, which is still about who they are rather than what they are doing. Purpose is the one dimension the entire fifty-year lineage has no slot for.
So a structural requirement was met with an administrative process. The purpose went into a form.
PROSE IN A SYSTEM NOBODY QUERIES
Justification fields on tickets. Impact assessments filed and shelved. Attestations that a use was consistent with the stated basis. Records of processing maintained in spreadsheets by people who had never seen the tables they described. All of it written in prose, stored somewhere no system queries, sitting adjacent to an access grant that contains no reference to it and is not constrained by it.
This is the moment the gap stopped being incidental and became structural. Before 2018 you could argue the model was merely inconvenient. After 2018, the thing regulators were asking about and the thing the architecture could describe were different objects. Every enterprise closed that gap with human labour, and got used to the cost.
One more irony worth recording. In the same period, zero trust became the consensus security posture: assume no implicit trust, verify every request, grant the least privilege for the shortest time. The industry adopted it with enthusiasm at the network and application layers. At the data layer, where the actual sensitive material lives, we kept standing grants attached to roles created years earlier, and called it governance.
The workarounds
became the architecture.
This is the part that has to be said plainly, because it implicates everyone, and because nobody in it did anything unreasonable.
Put yourself in the seat. You own data governance at a company with forty thousand employees. On Monday a team needs one additional column to finish a regulatory report due Friday. You could revise the policy that governs the whole domain, involve three other stakeholders, and land it in a month. Or you could create a role that grants exactly that column, add four people to it, and be done before lunch.
You create the role. It is the right call. It is the right call every time, and there are eleven of these a week.
- An audience needs a filtered view and the platform cannot express the filter, so you produce a copy. Cheaper this quarter than a dynamic policy.
- A request does not fit any existing pattern, so it becomes a ticket and a manual grant. Cheaper than modelling the case.
- Something breaks at two in the morning and someone uses break-glass credentials. The incident closes. The credentials stay.
- An engineer leaves and nobody can determine what one of her roles actually permits. Deleting it might break a pipeline nobody documented. It stays.
Now notice the asymmetry that governs all of this. Granting access has a named beneficiary who is grateful today. Removing access has a named person who gets blamed if something breaks tomorrow. There is no constituency for revocation. Entitlements therefore accumulate in one direction only, and the single force pushing back is the access review.
Which brings us to the most widely practised fiction in enterprise security. A manager receives a list of several hundred entitlements. They are named in a vocabulary invented by engineers who have since left. There is no indication of what data each one actually exposes, no record of whether it has ever been used, and no explanation of why it was granted. There is a deadline, and a compliance team that needs the campaign closed. The rational action is to approve everything.
Everybody involved knows this. It is performed anyway, because evidence of performance is what the auditor asks for.
THE ACCESS REVIEW, 1996 – PRESENT
The aggregate result, in essentially every large enterprise, is the same three conditions. Access is broader than anyone intends. It is older than anyone remembers. And the reason it was granted is either unrecorded or recorded in a sentence that means nothing to anybody now. This is frequently what people are describing when they say their governance programme is mature: the paperwork is complete, and the underlying state is unknown.
There is a plainer way to say all of this. Need-to-know is the oldest rule in information security. It predates computers, it is the first thing anyone is taught, and no security leader on earth would argue against it out loud. It is also not what any large enterprise is actually running. What they are running is need-to-have-asked-once, and the record of who asked, and why, is gone.
No individual decision in that chain was wrong. Every one was the cheapest correct answer available at the time, given a model that could not express what the business needed. That is what makes it structural rather than cultural, and it is why hiring more governance analysts does not fix it.
Why the industry
did not fix this.
Four categories of vendor sell into this problem. Each describes it accurately in its own vocabulary. None of them decides anything.
It is tempting to treat a fifty-year gap as evidence that the problem is intractable. It is more useful to look at who would have had to build the answer, and what building it would have cost them.
DATA PLATFORMS
Will build excellent policy — for themselves
A platform has every reason to ship strong native controls and no reason at all to ship a control plane spanning its competitors. A shared authorization layer commoditizes the platform and makes its customers portable. Expect world-class in-platform policy forever, and never a common one.
IDENTITY PROVIDERS
Cannot see the data
Identity resolves the actor and maps the entitlement graph with real sophistication, then hands the decision to controls whose only vocabulary is groups and roles. It does not know what is in the column, how sensitive it is, or what the request is for. Agent identity is the same handoff with a faster actor.
DATA SECURITY TOOLING
Built to observe, not to decide
Discovery, classification and posture management tell you what the data is, where it sits and where it is exposed. That is genuinely useful, and it is not a control. Nothing in the category stands in the path of a request and returns an answer to it.
GOVERNANCE, RISK, COMPLIANCE
Built to document afterwards
GRC platforms record that a decision was made, who signed off, and when the campaign closed. They are the system of record for the substitution described in Chapter II. They never make the determination; they file it.
The enterprise buys all four and still has nothing whose job is to answer a request. That is not a procurement failure. It is what the market had on offer.
Add to that a budget dynamic that ran for a decade. Detection could be bought and demonstrated within a quarter. Prevention required rewriting how access worked across every platform in the estate — a multi-year programme with no incident to point at, proposed by a security leader whose tenure averages shorter than the programme. Every rational actor bought detection. The aggregate effect was an industry that became extremely good at describing what had already happened.
None of this required anyone to be short-sighted. It required only that each party act in its own interest, which is the strongest possible reason to expect a gap to persist. Gaps that survive because of incentives do not close when someone points them out. They close when an outside force makes the old arrangement untenable.
Nobody designed this.
Everybody built it.
Fifty years of locally correct decisions, made by competent people under real constraints, compounding into a structure nobody would choose and nobody can now describe.
Nobody goes looking
for data any more.
The outside force turned out not to be a regulator or a breach. It was a change in who consumes data — and in what they need the data layer to be for.
Late 2022 put a general-purpose language model in front of every knowledge worker. Within a year copilots were embedded in the tools those workers already used, and for the first time the population capable of querying enterprise data was not limited to people who could write a query. In late 2024 a standard protocol for connecting models to tools and data removed the last integration barrier. By 2025 agents were in production, acting on behalf of named people, calling tools, and delegating subtasks to other agents.
The consumer changed.
For as long as enterprises have had data worth governing, the consumer of that data was a person holding a tool. The tool kept changing — a terminal, a spreadsheet, a BI dashboard, a notebook, a SaaS application with a query box — but the sequence never did.
A person had a question. They worked out what data might answer it. Then they went looking: asked a colleague, searched a catalog, opened a schema and guessed from the column names. They worked out what the data meant, which usually meant finding the one analyst who remembered why there were three revenue columns. They requested access. They waited. And then, finally, they used their tool to turn what came back into an answer.
Almost everything in the modern data stack exists to speed up one step of that sequence. Catalogs were built because finding was slow. Semantic layers and metrics stores were built because understanding was slow and error-prone. Self-service analytics was built so the last step did not require an engineer. Request portals and governance workflows were built because waiting was the bottleneck. Two decades of investment, a product category, and an entire professional discipline, all organized around one premise: a human being needs to find data and get permission to use it.
That premise is being removed.
Ask a model a business question today and the person does none of it. They do not know which tables were touched, and more to the point they do not want to. The question goes to a harness — a copilot, an AI analyst, an agent with tools — which decomposes it, works out what data would answer it, resolves what that data means from whatever context layer you have, writes the query, runs it, and renders the answer as something the person can read. The human's job has narrowed to two things: asking the question, and judging whether the answer is any good.
Be precise about what disappeared, because it is not the catalog and not the semantic layer. Those became more valuable, not less — they stopped being things a person browses and became the things a model reads. What disappeared is the human act of discovery. And discovery was the load-bearing assumption underneath governed access.
The access request was never the point. It was a workaround for the fact that finding data was slow.
WHY THE BOTTLENECK MOVED
By the time a person had identified the exact dataset they needed, they had already spent days on the problem. A few more days waiting for approval was proportionate, and any process that fit inside that waiting was effectively free. The entire apparatus of governed access — the ticket, the reviewer, the queue, the weekly meeting — is calibrated to the cost of human discovery.
Collapse discovery to a few hundred milliseconds and the request becomes the whole cost. Everything on either side of the decision got four orders of magnitude faster. The decision itself did not move at all.
Which is why the job of the data layer inverts. For twenty years the question a data leader was asked to answer was: how do we organize our data so people can find it, understand it, and be trusted with it? That question is close to finished. The one replacing it is: how do we make this estate something an agent can be safely authorized against, thousands of times an hour, on behalf of people who will never see a table name?
Those are not the same programme. The first is a discovery and enablement problem, and its artifacts are catalogs, documentation, training and self-service. The second is an authorization problem, and its artifacts are policy, identity, purpose and evidence. An organization can be genuinely excellent at the first and have done nothing whatsoever about the second. That describes most large enterprises today.
We will put a number on it, with the caveat that it is our own estimate and not anyone's published research: by 2028 we expect the large majority of enterprise data consumption — our working figure is close to nine in ten queries — to be issued by a model on someone's behalf rather than typed by a person. You do not have to accept that number. You only have to accept the direction, and then ask which of those two programmes your organization is currently staffed for.
What broke, precisely.
The naive reading of all this is that demand for data went up. The accurate reading is that five assumptions inherited from 1976 broke simultaneously, and every one of them was doing structural work.
Any one of these is a hard engineering problem inside the existing model. All five together are a different model.
Take the third one seriously for a moment, because it is load-bearing. Every access control system ever built, including the best attribute-based policy in the world, requires someone to anticipate what will be needed. You can write a policy covering a class of people and a class of data without naming individuals, which is a genuine advance. You still have to know, in advance, that this class of person may legitimately need this class of data.
An agent does not cooperate with that requirement. It decomposes a question you did not predict into steps you did not enumerate, reaching for data you never associated with that person's job, because the question was novel. You cannot pre-provision a question that does not exist yet. There is no version of pre-decided access that survives this, no matter how expressive the policy language becomes.
And the failure mode is quiet, which is what makes it dangerous. An agent denied data does not file a complaint or escalate to a manager. The workflow returns something unhelpful, a human in a hurry investigates, and the fastest available fix is to widen the grant. Over-provisioning is now the path of least resistance, it happens under deadline pressure, and it generates no incident and no record.
The organizations in the worst position three years from now will not be the careless ones. They will be the ones whose AI programme went well.
SUCCESS IS THE RISK VECTOR
What history says
happens next.
There is a pattern for what becomes of a decision that has to be made millions of times a day by everyone, in their own way.
It gets extracted. Not simplified, not automated away — moved out of every application and into one layer that makes it consistently and keeps the record.
- Machines needed to talk to machines across incompatible networks. Every vendor had a proprietary answer. The decision was extracted into a protocol stack, and the argument ended.
- Browsers needed to know whether a server was what it claimed. Every site had its own answer, most of them bad. The decision was extracted into certificates and a trust hierarchy.
- Applications needed to know whether a person was who they claimed. Every application had its own login table. The decision was extracted into federated identity, and now almost nobody writes one.
- Strangers needed to move money to strangers. The decision was extracted into card networks and clearing systems that carry both the authorization and its evidence.
In each case the decision did not become easier. It became someone's specific job, performed in one place, the same way every time, with a record. And in each case the extraction happened not when the problem was first understood, but when volume made local handling impossible.
Authorization over enterprise data is the last major decision in this stack that has not been extracted. It is still made inside every platform, in every dialect, by whichever team happens to own that system, with no shared record of what was decided or why. It has survived in that condition because the volume was survivable and the incentives, as Chapter VII describes, pointed away from fixing it.
AI is the forcing function, because it is the first consumer of enterprise data that can neither wait for a person nor be provisioned in advance.
WHY NOW, AND NOT IN 2003
This is not a prediction about a product category, and it does not depend on anyone naming one. It is an observation about where a decision ends up when it has to be made a million times a day and nobody can keep a straight answer to what was decided last quarter.
Two versions
of 2028.
Neither of these requires anyone to be negligent. They differ only in whether the decision had somewhere to live.
THE FIRST VERSION
Nobody kept the record.
Access was granted broadly, because narrowing it was slow and the programme had a date. Service accounts accumulated privileges no one can now account for. An agent, asked an ordinary question by an ordinary employee, returned compensation data to someone who should never have seen it; the review found that the role permitting it was created in 2019 for a reason nobody remembers.
Then an examination arrives, and the honest answer to who could see this, and why is that nobody kept the record — because the record was always assembled afterwards from platform logs, and the logs do not contain the reason.
Elsewhere in the same company, three AI programmes were cancelled. Not because they did not work. Because no one could prove they were safe, and the only available way to make them safe was to make them useless.
THE SECOND VERSION
Every request was decided.
Every request for data — from a person, an agent, or an agent acting for an agent — was decided in one place, against one set of rules, at the moment it was made, with the actor, the data, the declared purpose and the context all visible at once.
Grants lasted as long as the task and then stopped existing. The record was written as each decision was made, so the examination is a query rather than a project, and the answer covers last quarter as easily as this morning.
And because the decision is fast and narrow, nobody had to choose between shipping the agent and controlling the data. That is the trade every enterprise is currently making, and most are making it badly in both directions at once.
The difference between those two years is not governance maturity, headcount, or how good the policies look on paper. Both versions can be staffed by the same people with the same intentions and the same budget. The difference is architectural: whether the decision about what a request may return has a single place to be made, or is inferred after the fact from five systems that were never asked the question.
What has to exist
instead.
Four requirements. They follow from the history rather than from anybody's product roadmap, and three of them are why previous attempts failed.
The thing that has to exist has a name, and it is deliberately unexciting: an authorization layer. Not a new place to keep data, and not a replacement for anything you run. One layer, whose entire job is to decide what a given request may return, and to be able to say afterwards why. Four requirements define it.
One place where all four facts are present at once.
The actor, and who they are acting for. The data, and how sensitive it is. The declared purpose. The moment, with whatever context that carries. No layer in the stack today sees all four: identity cannot see the data, the platform cannot see the authority, classification tools cannot see the request, and the compliance system sees everything too late. A decision that depends on four facts has to be made where four facts exist.
It decides per request, not per identity.
The output is not a permission that persists. It is a determination about one request — permit, withhold a column, filter to a subset, refuse, or send it to a person — scoped to that task and expiring with it. This is the specific break from 1976, and everything else follows from it. It is also, precisely, need-to-know — mechanised, and running for the first time at a volume no human reviewer could ever have served.
It is enforced natively, where the data already lives.
This is the requirement that killed the last attempt. A decision that cannot be enforced inside the system holding the data is an opinion. Which means no proxy in front of the warehouse, no copy of the data in a new place, no rerouting of queries through a vendor. The platform applies its own controls; the layer tells it what they are for this request.
It writes the evidence as it decides.
Not reconstructed later from query history, which is the current practice and which loses the two things that matter most: the authority the request was made under, and the reason. Actor, delegation chain, data, purpose, outcome — written at the moment of determination, because that is the only moment all of it is known.
And what it must not be: a new place to move your data, a replacement for your identity provider, or a second policy model that has to be kept in agreement with the first.
THREE WAYS TO FAIL AT THIS
Note what is absent from that list. Nothing about machine learning, nothing about a new interface, nothing requiring the estate to move. The requirements are almost boring, which is what you would expect of infrastructure. The reason it has not been built is not that it is conceptually hard. It is that, per Chapter VII, nobody in the market had a reason to build it and no single platform could.
Where we come
into this.
Two things should be said honestly. The first is that we did not set out to build an authorization layer. We arrived at it, and only in retrospect does the path look deliberate.
Chapter II describes where we came in: making attribute-based policy something the people who own the rules could author for themselves. In 2015 that was the entire company. By 2020 the binding constraint had moved from enforcement to provisioning, so we built request and exception workflows, and access stopped having to be assembled by hand. Each era demanded one of the four requirements above, and by the end of the third we were holding all of them at once. Ten years, three eras, tens of millions of access decisions a year, in banks, pharmaceutical companies, insurers and government agencies — the places where being wrong is not an option.
USERS UNDER ONE POLICY MODEL AT A SINGLE BANK, ACROSS FIVE LINES OF BUSINESS AND 40,280 DATA SOURCES
ACCESS GRANTS ISSUED AT A GLOBAL MANUFACTURER WITH NO HUMAN IN THE LOOP
QUERIES PROTECTED EVERY MONTH AT A PHARMACEUTICAL COMPANY — DAYS TO MINUTES FOR CONFIDENTIAL DATA
LEGACY PERMISSIONS AT ONE ENTERPRISE, REPLACED BY SIX POLICIES
The second thing to be honest about is that we have an obvious commercial interest in this argument being true. So judge it the way you would judge any claim from an interested party: against the history, which is a matter of record, and against your own estate. Ask what your organization would actually have to do to answer the question in the prologue. If the answer is a project, the argument holds regardless of who is making it.
What is new, as of September 2026, is the commitment rather than the capability. We are naming the thing we have been building, because naming it means declining to be several other things. Immuta is the data authorization layer. Every request, decided against your policy, enforced inside the systems you already run, recorded as it happens. That is the whole job, and everything we build from here serves it.
The architecture does not change as this matures. What changes is how much of it runs without a person. That is what parts two and three are about.
PART ONE
THE AUTHORIZATION LAYER
YOU ARE HERE
How we lost it
A history of data access control. Fifty years of deciding in advance because deciding per request was impossible, why every attempt to patch it made things worse, and why agents end the model rather than strain it.
PART TWO
AUTHORIZATION INTELLIGENCE
NEXT
Proving it
Authorization intelligence. Millions of decisions a day, every one answerable — how compliance, audit and the business see what every human and every agent was allowed to see, narrow what is over-provisioned, and prove it continuously instead of reconstructing it at audit.
PART THREE
AUTONOMOUS AUTHORIZATION
FORTHCOMING
Deciding it
Autonomous authorization. Just-in-time access at machine speed, and the line we will not cross: the execution becomes autonomous, the authority stays human.
No one is coming to reduce the number of questions.
The volume is going one direction. The window in which an answer is useful is getting shorter. The standard of proof is not moving, and no regulator has ever accepted scale as a defence. Every year this is deferred, the estate accumulates more standing access granted for reasons that are already unrecoverable.
The layer does not come into existence because a standards body ratifies it or an analyst firm names the category. It exists when an organization decides that every request for its data will be decided in one place, against one set of rules, with the reason written down — and then runs that way. That is a decision, not a purchase, and it is one of the few architectural decisions left that a company can still make deliberately rather than inherit.
Make it before the volume makes it for you.
PART TWO, AUTHORIZATION INTELLIGENCE, PUBLISHES SHORTLY. PART THREE FOLLOWS.
Notes & sources
Dates and attributions for the historical claims above, in roughly the order they appear.
- Multics — project begun 1965 (MIT, Bell Labs, General Electric); origin of much modern access-control vocabulary.
- B. Lampson, “Protection,” Princeton Conference on Information Sciences and Systems, 1971 — the access matrix.
- J. P. Anderson, Computer Security Technology Planning Study, USAF, 1972 — the reference monitor.
- D. Bell and L. LaPadula, Secure Computer Systems, MITRE, 1973 — multilevel security model.
- E. F. Codd, “A Relational Model of Data for Large Shared Data Banks,” CACM, 1970.
- P. Griffiths and B. Wade, “An Authorization Mechanism for a Relational Database System,” ACM TODS 1(3), September 1976, 242–255 — the origin of GRANT and REVOKE, in IBM's System R.
- TCSEC (“Orange Book”), DoD 5200.28-STD, 1985.
- D. Ferraiolo and D. R. Kuhn, “Role-Based Access Control,” 15th National Computer Security Conference, October 1992, 554–563. Formalized as ANSI/INCITS 359-2004. NIST's 2011 economic assessment estimated its RBAC research saved industry over $1.1 billion.
- R. Sandhu et al., “Role-Based Access Control Models,” IEEE Computer, February 1996.
- OASIS XACML — v1.0 ratified February 2003; v3.0 January 2013. Defines the policy administration, decision and enforcement points.
- Federated identity — SAML 2.0 (OASIS, 2005); OAuth 2.0 (RFC 6749, 2012); OpenID Connect Core 1.0 (2014); SCIM (IETF, 2011 and 2015).
- NIST SP 800-162, Guide to Attribute Based Access Control Definition and Considerations, 2014 (updated 2019).
- GDPR — Regulation (EU) 2016/679, in force 25 May 2018; purpose limitation and data minimization, Article 5(1)(b)–(c). CCPA effective 1 January 2020. HIPAA minimum necessary standard, 45 CFR 164.502(b).
- Zero trust — J. Kindervag, Forrester, 2010; formalized in NIST SP 800-207, August 2020.
- Model-to-tool connectivity — the Model Context Protocol, published November 2024, standardizing how models reach external tools and data.
- Identity population — non-human to human identity ratio of approximately 144:1 in 2026, up from 92:1 the prior year, per industry identity-security survey data.
- Share of data consumption issued by models — the figure of roughly nine in ten queries by 2028 is Immuta's own working estimate, not published analyst research, and is offered as a direction of travel rather than a forecast.
- Deployment figures in the coda are drawn from named Immuta customer deployments in financial services, manufacturing and pharmaceuticals.