AI tools inherit the permissions of the user running them. If your access controls were already too broad, AI makes that problem orders of magnitude worse. The principle of least privilege has never mattered more, and most organisations are nowhere near applying it to their AI systems.
The principle of least privilege is one of the oldest and most well-established concepts in information security. Give users, systems, and processes access to precisely what they need to do their job, and nothing more. It is simple in principle and difficult in practice, as anyone who has tried to implement it across a large enterprise environment will confirm.
AI changes the stakes considerably. When a human user has overly broad access permissions, the risk is that they might inadvertently or deliberately access data they should not. When an AI system has overly broad access permissions, the risk is that it will routinely and automatically traverse data it was never intended to reach, at a speed and scale no human could match, and surface or act on that data in ways that are difficult to predict and harder to reverse.
Most enterprise access control models were not designed with AI in mind. Rebuilding them to account for AI is not optional. It is the foundational security task of the current era.
Why AI Makes the Access Problem Worse
A human user with overly broad access permissions navigates data manually. They open files, browse directories, and search for things. Their access to the full breadth of their permissions is limited by time, attention, and intent. In practice, most users with excessive permissions never exercise the majority of them, not because the controls are working but because they have neither the time nor the motivation to explore everything they could theoretically reach.
An AI system with the same permissions operates differently. It does not browse. It processes. Given a query, it will traverse every data source within its access scope to construct the best possible response. It does not distinguish between data the user is supposed to access and data the user merely has technical permission to access. It does not exercise discretion. It exercises permissions.
This means that access control failures which have been effectively dormant for years, because no human ever had the time or inclination to exploit them, become active risks the moment an AI system is introduced with those same permissions. The AI will find the data. It will use it. And it will do so entirely within the bounds of what it was technically permitted to access.
The Identity Problem for AI Systems
When a human user authenticates to an enterprise system, their identity is well understood. They have a named account, a defined role, a set of permissions that can be traced to a business justification, and an access review process that, in well-governed organisations, periodically validates that those permissions remain appropriate.
AI systems are often provisioned with service accounts or API credentials that are scoped far more broadly than any individual user account would be, because it is easier to grant broad access once than to define precise access for every use case the AI might encounter. The result is an AI identity that can access more of the enterprise data estate than most human users, with less scrutiny, fewer controls, and no access review process.
This is not theoretical. It is the default state of most AI deployments that have not been subject to explicit access control design. The service account used by an AI integration is often a domain admin or a global reader, because someone needed it to work quickly and those roles guaranteed it would. That account then sits in production indefinitely, with permissions that were never reviewed and access that was never scoped to what the AI actually needs.
Applying Least Privilege to AI: What it Actually Involves
Applying least privilege to AI systems requires the same discipline as applying it to human identities, with some additional complexity. The starting point is defining precisely what each AI system needs to access in order to fulfil its defined function, and granting access to exactly that and nothing more.
For AI tools integrated with Microsoft 365, this means scoping Graph API permissions to the minimum required for the specific use case. A tool that needs to read a user's calendar does not need access to their email. A tool that needs to create documents in a specific SharePoint site does not need read access to the entire SharePoint estate. The granularity of Microsoft Graph permissions makes precise scoping possible. It requires deliberate design to achieve it.
For AI systems accessing databases or data warehouses, access should be scoped to specific schemas, tables, or views relevant to the AI's function. Read-only access should be the default unless the AI genuinely needs to write. Data classification should inform access decisions, with AI systems excluded from accessing data above their required classification level.
For agentic AI systems that take actions rather than simply querying data, the access control model needs to account for the actions the agent can perform, not just the data it can read. An agent that can send emails, modify records, or call external APIs needs its action scope defined and constrained as rigorously as its data access scope.
The Data Estate Audit You Cannot Avoid
Applying least privilege to AI systems requires understanding what data exists, where it lives, how it is classified, and who and what currently has access to it. In most enterprise organisations, this understanding is incomplete.
Data governance work that has been deferred for years because the consequences of incomplete access controls were manageable becomes urgent when AI is introduced. You cannot scope AI access appropriately if you do not know what you are scoping it away from.
A data estate audit for AI readiness should identify all data repositories that AI systems will or could access, classify the data held in each repository by sensitivity, map current access permissions against that classification, identify permissions that exceed what is justified by business need, and produce a remediation plan that brings access controls into line before AI deployment.
This is not a small piece of work in a large organisation. It is, however, work that needed to be done regardless of AI. AI has simply made the consequences of not doing it visible and immediate rather than theoretical and deferred.
Sensitivity Labels: The Technical Control That Travels With the Data
For organisations in the Microsoft ecosystem, sensitivity labels implemented through Microsoft Purview provide a data-centric control that complements permission-based access controls. Labels applied to documents and emails travel with the content, persist across storage locations, and can be configured to restrict what AI systems can do with labelled content regardless of where it is accessed from.
A document labelled Highly Confidential can be configured so that Copilot cannot summarise it, include it in responses, or reference its content in outputs, even if the requesting user has permission to open the document directly. This provides a layer of AI-specific control that operates independently of, and in addition to, permission-based access controls.
The prerequisite is a sensitivity labelling implementation that is comprehensive, consistent, and maintained. Partial labelling provides partial protection. A document that should be labelled Confidential but is not will not benefit from the controls that labelling provides. Labelling programmes that started well and drifted are a common pattern, and they represent a material gap in AI access control.
Access Reviews for AI Identities
Human user access is subject to periodic access reviews in well-governed organisations. AI system access should be subject to the same discipline. Every AI system in production should have its access permissions reviewed on a defined schedule, with any permissions that cannot be justified by current business need removed.
AI access reviews should also be triggered by changes in the AI system's function, changes in the data landscape it accesses, and changes in the regulatory or contractual context governing the data it handles. A permission that was appropriate when the AI was first deployed may not remain appropriate as the system evolves or as the sensitivity of the data it accesses changes.
Ownership of AI access reviews should be explicit. Someone in the organisation should be accountable for each AI system's access profile, with the authority and responsibility to initiate remediation when reviews identify permissions that are no longer justified.
The Bottom Line
Access control is not a new problem. Least privilege is not a new concept. What AI has changed is the consequence of getting it wrong. Permissions that were technically excessive but practically harmless become actively exploitable the moment an AI system is introduced with those same permissions and the capacity to traverse them at scale.
The organisations that will navigate AI deployment most securely are those that treat the access control model as the foundation, not an afterthought. That means auditing the data estate before deployment, scoping AI permissions with precision, implementing sensitivity labelling consistently, and subjecting AI identities to the same access review discipline as human ones.
If you are deploying AI tools and want to ensure your access control model is fit for purpose, or if you suspect your current permissions are broader than they should be and want to understand the exposure that creates, we can help.
