The Principle of Least Privilege Doesn’t Change

By this point in the series, we have given our AI worker a job, placed it somewhere in the organization, and started treating it less like a shiny new piece of software and more like something that actually performs work. That is where the conversation gets interesting, because once people see what AI can do, someone inevitably asks the next question: “What else can we connect it to?”

Modern AI platforms make that question incredibly easy to ask. They can connect to SharePoint, email, Salesforce, ServiceNow, GitHub, financial systems, HR platforms, collaboration tools, databases, and just about anything else with an API. From a technical perspective, that is impressive. From a security perspective, it is also the moment to ask a much less exciting question: What does this AI actually need?

Fortunately, cybersecurity already has an answer. We call it the Concept of Least Privilege, and despite everything artificial intelligence may change about technology, least privilege isn't a concept that needs reinventing. The idea remains simple: an identity should receive only the access it needs to perform its assigned role. We have applied that principle to employees, contractors, administrators, applications, and service accounts for decades. AI should not receive an exemption simply because it can summarize a 200-page document in twelve seconds.

In the previous post, I argued that AI needs something resembling a job description. That job description becomes especially important when we begin deciding what the AI can see and what it can do. If the AI works for Finance, it may need access to budgets, invoices, accounting data, forecasts, and approved financial reporting systems. It does not need access to employee disciplinary records. An Engineering AI may need source code, architecture documentation, development systems, and build pipelines, but it has no obvious reason to access payroll. A Marketing AI may need campaign data, customer demographics, and approved product documentation, but it does not need penetration-testing reports or incident-response notes.

The job should determine the access, not the fact that an integration happens to exist.

This sounds obvious when we talk about employees. If someone started in Marketing on Monday and immediately requested access to Finance, HR, Security, Legal, executive email, source code, and every SharePoint site in the company, most organizations would ask a few questions before approving the request. When AI makes essentially the same request through a list of connectors, however, organizations sometimes treat it very differently.

“Connector” sounds harmless. It sounds like a feature. It sounds like something we should enable because otherwise we are not getting the full value of the product.

From an identity perspective, though, a connector is access.

Connecting an AI to SharePoint permits it to retrieve information from SharePoint. Connecting it to Salesforce, ServiceNow, GitHub, or email creates a trust relationship with those systems. The terminology may be new, but the governance problem is not.

The risk grows because AI can use access very differently from a human employee. A person may technically have access to 50,000 documents and never open more than a few hundred of them. An AI can search all 50,000. A person may not realize that two pieces of information become sensitive when combined. AI is specifically designed to make those connections. A human could miss an old report buried six folders deep on a disregarded SharePoint site. AI may retrieve it in seconds.

That capability is exactly why organizations want AI. We want systems that can search faster, discover patterns, and surface knowledge people might otherwise miss. But those same capabilities make excessive access far more consequential.

Overpermissioning is not new. People change jobs and keep access from previous roles. Contractors receive broader permissions than necessary. Service accounts accumulate privileges because nobody is quite sure what will break if someone removes them. Applications get broad API permissions because figuring out the exact permissions required would take another meeting, and nobody wants another meeting.

AI raises the stakes.

An overpermissioned employee is a risk. An overpermissioned AI can be a risk at machine speed. The uncomfortable part is that AI doesn't need malicious intent to create a problem. It may simply be extremely efficient at using exactly the permissions we gave it.

That is why organizations need to separate capability from authorization. We need to distinguish between “Can the AI do this?” and “Should the AI be allowed to do this?” Those questions are not the same. A security AI may be technically capable of deactivating a compromised account after reviewing an alert, but that does not mean it should automatically have permission to do so. A finance assistant may be able to interact with an accounts-payable system, but reviewing an invoice and approving payment are very different levels of authority. A customer-support AI may be able to issue a refund, but that does not mean every support interaction should have access to that capability.

Humans already understand the difference between “can” and “may.” Most employees can walk into the CEO’s office, sit behind the desk, and rearrange the furniture. Corporate policy generally discourages this. Capability has never automatically meant authorization, and AI does not change that principle.

This becomes even more important as AI moves from reading information to taking action. A substantial difference exists between an AI that recommends deactivating an account and one that actually disables it. The first produces advice. The second creates operational impact. Reading a firewall rule is different from changing it. Drafting an email is different from sending it. Reviewing a payment is different from approving it.

Least privilege for AI must therefore consider both the information it can consume and the actions it can perform. An AI may begin by observing approved information and producing analysis. Once the organization understands its behavior, it might be allowed to recommend actions. Later, it could prepare a change, ticket, response, or transaction for human approval. Only after sufficient testing should it be given authority to execute narrowly defined actions on its own.

Each increase in authority increases privilege, and each should have a business reason.

Another challenge appears when AI operates using delegated user access. Many enterprise assistants are designed to act within the permissions of the person using them, which initially sounds reasonable. If an employee can access a document, the assistant helping that employee should be able to access it too.

The problem is that a user’s total available access may be much broader than what the AI needs for a particular task.

Employees accumulate permissions over time. They may belong to old SharePoint sites, project groups, collaboration spaces, email archives, and applications they barely remember having. They may technically be authorized to access all of it, but that does not mean every AI interaction should be able to search it all.

A considerable difference exists between what a user can access and what the AI should access for the job at hand. If someone asks an AI to summarize a security incident, it does not need to search every file the user has ever been authorized to open. If someone asks for assistance drafting a budget proposal, the AI probably does not need to search six years of personal email. The user’s maximum permission boundary does not necessarily need to become the AI’s working boundary.

This is one reason organizations ought to be cautious about building the all-knowing corporate AI. The idea is attractive: one assistant that knows everything. Ask it about Finance, HR, Engineering, Security, Legal, customer information, corporate strategy, and what is being served in the cafeteria.

From a user-experience perspective, that seems convenient. From an identity perspective, however, we have created an account with extraordinary visibility across the organization.

Cybersecurity has spent years trying to reduce the number of highly privileged identities in our environments. We separate administrator accounts, use privileged access management, monitor sensitive activity, and create stronger controls around identities that can touch critical systems. Creating one AI with access to everything would move us in exactly the opposite direction.

A better approach may be multiple AI identities with particular institutional roles. A Finance AI knows Finance. A Security AI knows Security. An Engineering AI knows Engineering. A Customer Support AI knows what it needs to support customers. Each identity has a purpose, an owner, and an access boundary appropriate to its work.

That may be less exciting than building the digital equivalent of an all-knowing corporate oracle, but it is far easier to govern. It also lowers the chance that someone asks an innocent marketing question and receives an answer informed by a confidential legal investigation, which is generally considered a positive outcome.

Another AI concept deserves examination through the lens of least privilege: context. We hear constantly that greater context creates better AI responses, and technically that is often true. More relevant information can improve a model's ability to answer questions accurately.

But there is a major difference between greater context and appropriate context.

If someone asks a Finance AI to forecast next quarter’s operating costs, it may need budget information, historical spending, current contracts, and approved forecasts. It does not need employee disciplinary records, vulnerability reports, or confidential legal strategy. Those sources would provide supplementary context, but not useful context.

At some point, “greater context” becomes “more data than the identity should have.”

That is where least privilege begins to overlap with data limitation. The goal should not be to provide AI with every piece of information the organization possesses. The goal should be to provide enough authorized information for the AI to perform its assigned task accurately.

In many cases, limiting the AI to authoritative, relevant data may improve its work because it reduces the outdated, contradictory, or unrelated material the system has to consider. Sometimes better security and better AI performance are not competing goals. Sometimes giving the AI less information produces a better answer.

Least privilege is also an ongoing process, not a one-time configuration. AI roles will change just as employee roles change. Projects begin and end. Data sources get added. Agents gain capabilities. A temporary connector used during a project may no longer be required six months later.

Unfortunately, cybersecurity history shows that temporary permissions can easily become permanent.

Someone adds access for a legitimate reason. Another process becomes dependent on it. The first project ends, and nobody wants to remove the permission because nobody is entirely sure what might stop working. Five years later, an auditor asks why a service account has access to eleven systems, and everyone in the room suddenly becomes fascinated by the ceiling tiles.

AI can easily make this worse. Organizations will create agents quickly. Those agents will receive tokens, API permissions, connectors, and repository access. People will change jobs. Projects will end. Vendors will change. Without deliberate lifecycle management, companies will eventually discover AI identities whose original purpose nobody remembers but whose permissions remain surprisingly impressive.

We already have enough mysterious service accounts. We do not need mysterious service accounts that can also write quarterly reports.

This makes periodic access reviews especially important. Someone should routinely review each AI identity and ask whether its permissions still fit its job. Does the AI still perform the same function? Does it still need each connector? Has the business process changed? Has the sensitivity of the data changed? Did something that started as a six-week proof of concept quietly become production three years ago?

Those reviews should not belong exclusively to cybersecurity. The business owner should be involved because the business owns the job. IT can implement the architecture and security can enforce the controls, but the business should be able to explain why significant permissions exist.

That is why least privilege should not be viewed only as a security restriction. It is a business control. It reduces blast radius when something goes wrong. It limits accidental disclosure. It improves accountability. It makes auditing and investigations easier. With AI, it also limits what the system can retrieve, correlate, summarize, and act upon.

Artificial intelligence may change many parts of how organizations perform work, but it does not invalidate what we have already learned about identity. If an AI has a job, give it the information it needs to do it. If it needs to take action, give it only the authority necessary for those actions. If additional access becomes necessary, expand it deliberately. If the role changes, review the permissions. If access is no longer needed, remove it.

Do not connect everything simply because the platform makes it easy, and do not create a single AI identity with visibility into the entire organization simply because users would find it convenient.

The Concept of Least Privilege remains exactly what it has always been: an identity should receive the minimum access needed to perform its assigned role.

AI does not make that principle outdated. If anything, AI makes it more important, because the real danger may not be that an AI intentionally misuses excessive permissions. The more realistic problem is that it uses every permission we gave it exactly as designed, only faster and at a scale no human employee could reasonably match.

And that leaves us with another problem. Once we decide what an AI should be allowed to access, someone has to remain responsible for those decisions. Someone needs to approve the connectors, review the permissions, watch for role changes, decide when additional authority is justified, and answer questions when the AI does something unexpected.

In other words, every AI needs a manager.

That is where we go next.