AI Readiness Is a Permissions Problem, Not a Data-Cleaning One

The Checklist Blind Spot

We've looked at most of the AI readiness checklists circulating among enterprise teams this year, and they tend to read remarkably alike. One widely circulated version runs to 60 questions. A shorter version many teams use covers 20. Read either closely and a pattern shows up fast: the overwhelming majority of the questions are about the data itself, its quality, its structure, its lineage, whether it is deduplicated, whether it sits in one place or six. Almost none of them ask who is allowed to see it, or under what conditions a system should be allowed to pull it.

That omission mattered less when AI meant a model answering questions typed into a prompt box. It matters a great deal more now that AI increasingly means an agent with standing retrieval access into a company's own systems: its CRM, its file shares, its support tickets, its HR records. A dashboard built by an internal engineering team is a known, bounded piece of software with a fixed, reviewed set of permissions. An agent asked to help with customer queries is not bounded in the same way. It can be asked, in plain language, to find things nobody explicitly scoped it to look for, and it will generally try.

Clean Data and Safe Data Are Different Things

Checklists built around data quality are also, frankly, easier to standardise. A field is either populated or it isn't. A record either carries a lineage tag or it doesn't. Access and permissioning questions are messier, because the right answer depends on how a specific organisation is actually structured: who reports to whom, which teams handle regulated data, which systems were never designed to be queried by anything other than the single application that originally owned them. That messiness is probably why so few checklists go near it. It is also exactly why skipping it is the riskier gap to leave open.

A dataset can be immaculate, fully deduplicated, consistently labelled, every field traceable to its source, and still be the wrong thing for a given system to retrieve on demand. Clean HR records are still HR records. A clean legal correspondence archive is still privileged correspondence. A readiness checklist that stops at whether the data can be trusted has answered a real question, but not the one that actually determines whether deploying an AI system against that data is safe.

This is the distinction that Witness AI's research into agentic access control makes directly. AI agents routinely end up with broader effective access than any individual human user would be granted, because permissions tend to get configured once, loosely, at the point of integration, and nobody revisits them as the agent's capabilities, and its reach, expand. The data quality work was done. The access design work was skipped.

What Least Privilege Means Once the User Is an Agent

Microsoft's security team published a detailed piece on this in July 2026, arguing that identity and access management for AI agents needs to be treated as its own discipline rather than a minor extension of identity systems built for human employees and static service accounts. Their core argument is that an agent's access should be scoped to the specific tool call it is making at that moment, not to a standing credential that quietly accumulates reach as more systems get connected to it over time.

That is a genuinely different kind of exercise to tidying a dataset. It means deciding, before a model gets retrieval access to anything, which roles can see which categories of record, under which conditions, and with what gets written to an audit trail when they do. It means an agent fielding a facilities question should not have the same retrieval reach as one fielding a payroll question, even when both sit on the same underlying model and the same data warehouse. None of that shows up on a checklist built around field names and lineage diagrams.

Tool binding matters as much as role binding here. An agent that can call a function to read a customer's basic record and a separate function to read that customer's payment history should not automatically be granted both just because one request happened to touch both tables behind the scenes. Each capability an agent can invoke is its own authorisation decision, not a side effect of whichever database connection happened to get wired up first. Granting access function by function and request by request, rather than wholesale at the point of integration, is a slower way to bring an agent online. It is also the only way to keep a clear, auditable record of what the agent was actually permitted to do at the moment it did it, rather than reconstructing intent afterwards from a system log.

The Governance Exercise Most Checklists Skip

This is the part of AI readiness that our own AI Readiness assessment spends the most time on, because it is the part almost every public checklist leaves out. Before any retrieval layer goes anywhere near an organisation's historic data, we work through that data estate and classify it by sensitivity and by who should legitimately be able to reach it, department by department and record type by record type, rather than accepting the default that an AI integration can see everything the connection happens to point at. That classification work produces the actual permission map a system runs on afterwards. It is a design and governance exercise, not a data cleaning one, and it has to happen before authorisation is granted, not as a retrofit once something has already gone wrong. That same classification work also defines what gets logged afterwards: a permission map stating which roles can reach which records only holds up in practice if there is a durable record of what was actually accessed, when, and under whose authorisation, which a flat data quality checklist has no reason to produce, because it was never asking the access question to begin with.

None of this makes data quality irrelevant. Bad lineage still produces bad answers, and an organisation with scattered, duplicated records has real work to do before any of the rest of this applies. But quality is a precondition, not the finish line. A company can have the cleanest dataset in its sector and still hand an AI agent access it was never supposed to have, simply because nobody separated whether the data is good from who the data is for. The 60-question checklists and the 20-question checklists are both, in their own way, correct about what they measure. The actual readiness question is the one most of them never ask.

Sources

• Witness AI, 'AI Agent Access Control', witness.ai.
• Microsoft, 'Least Privilege for AI Agents: Identity, Access, and Tool Binding', microsoft.com (16 July 2026).