Why least privilege may need a companion: least context
Here’s a funny thing about enterprise AI. We spend a lot of time talking about what an agent should be allowed to do, but much less time talking about what it should be allowed to know.
I think that is going to become a much bigger issue.
A lot of enterprise agent design still starts from a fairly sensible assumption: if the user can access the data, the agent acting on their behalf probably can too. That lets companies reuse existing permissions instead of inventing an entirely new security model for AI.
But I am not sure the assumption holds up particularly well once agents start operating across several systems at once.
A CFO might legitimately have access to payroll, forecasts, board papers, contracts, legal correspondence and acquisition material. If they ask an agent to arrange a meeting, prepare a market summary or compare travel options, should all of that information even be within reach of the task?
The user is authorised. The agent may be authorised. The data may be completely legitimate.
And yet it still feels wrong.
That is the gap I think we need to explore.
User access and task access are not quite the same thing
In our previous piece, Why Enterprise AI Keeps Hitting the Read-Only Ceiling, I looked at what happens when agents move from making recommendations to actually changing things.
There is another boundary underneath that one.
Before we decide what an agent should be allowed to do, perhaps we need to get much better at deciding what information should enter the task in the first place.
Take employee onboarding. An HR director may legitimately have access to a large amount of information about a new employee: salary, health adjustments, performance history, previous correspondence, organisational structure and security information.
The onboarding agent probably needs the employee’s name, role, manager, location, start date and required systems. That may be enough to complete the job.
Giving the agent everything simply because the HR director can see everything is technically neat. Architecturally, I am not sure it is particularly sensible.
This is already showing up in the way agent security is evolving. Microsoft’s current guidance on least privilege for AI agents treats identity, scope, tool access and auditability as things that need to be deliberately defined before autonomy expands. It also frames the initiating user, the agent and individual tool calls as separate trust decisions rather than assuming one broad permission should cover the whole chain. Microsoft Learn
That is an important step.
But it still leaves a slightly different data question:
Even if the agent is allowed to retrieve something, does it actually need it?
We have lived with messy permissions for years
This is not really a new problem.
Anyone who has worked inside a large company knows how access evolves. You join a project, someone gives you access to a folder, you change roles, nobody removes it, another system gets added, and three years later you can still see things you probably no longer need.
Companies have lived with this partly because humans introduce quite a lot of friction.
You need to know the information exists. You need to know where to look for it. You have to search for it, understand it and then decide whether it is relevant.
Agents remove much of that friction.
That is one of the reasons they are useful. It is also one of the reasons the old permission model starts to look a little uncomfortable.
An agent can search documents, query a CRM, inspect operational data, call an API and combine the results in seconds. Things that were technically accessible before suddenly become practically accessible at scale.
The agent has not broken any rules.
It has simply become extremely efficient at using all of the access we already gave people.
That changes the risk.
Availability is not the same as relevance
Imagine a team working on an acquisition. They have access to forecasts, contracts, board materials, integration planning, legal advice and due-diligence documents.
Someone asks an AI agent to summarise the main commercial risks.
The agent searches everything it can reach and produces a very good answer. Buried in that answer are parts of privileged legal advice because the agent quite reasonably concluded that those documents were relevant to “risk”.
From a search perspective, it did exactly what we asked.
From a governance perspective, something more complicated has happened.
Nothing was hacked. No permission was bypassed. The agent simply crossed a boundary that humans normally handle with judgement.
This is exactly the sort of thing Legal teams are becoming nervous about, and I do not think that nervousness should simply be dismissed as resistance to AI. Sometimes Legal is pointing at an architectural problem before the rest of us have properly named it.
The privacy world is arriving at a similar conclusion. The ICO’s work on agentic AI puts particular emphasis on purpose limitation and data minimisation: define why the information is needed, and then limit what is processed to what that purpose actually requires. It specifically warns against giving agents access to information simply because it might prove useful later.
That sounds like regulatory language.
But underneath it is a very useful architecture principle.
Maybe we need “least context”
Security already has a good principle for this world: least privilege.
Give a user or system only the permissions it needs.
I think AI may need a companion principle.
I would call it least context.
Give the agent only the information it needs for the task it is doing now. Not everything the user can see, not everything a connected system can return, and not everything that might theoretically become useful.
Just what the task actually requires.
That sounds obvious when you write it down. In practice, a lot of current AI architecture still moves in the opposite direction.
More tools. More connectors. More retrieval. Larger context windows. More data “just in case”.
There is a security parallel here too. OWASP describes excessive agency in terms of excessive functionality, excessive permissions and excessive autonomy. Context may turn out to have a similar problem: simply because information can be exposed to an agent does not mean it should be.
For the last few years, AI teams have largely been taught that more context improves answers.
Enterprise AI may force us to learn the opposite lesson as well.
Sometimes a better agent is the one that knows less.
This is not just about privacy
There is another reason I like the idea of least context.
Too much context can also make the AI worse.
Imagine an agent investigating a customer problem. It retrieves CRM history, billing information, support cases, product telemetry, old contracts, previous account-owner notes and several years of archived records.
Some of that information is stale. Some is contradictory. Some was written before a contract changed. Some is simply irrelevant.
We tend to talk about context windows as though filling them is inherently useful.
I am not convinced that is the right objective.
The job is not to give the agent the maximum possible amount of information.
The job is to give it the smallest useful representation of reality.
That is a very different design goal.
It also changes the role of the data team. Instead of asking, “How do we make more enterprise data available to AI?”, the more useful question becomes, “How do we construct the right view of the enterprise for this task?”
That is a much more interesting problem.
MCP makes this more important, not less
We touched on this in MCP, AI Agents and Live Enterprise Data.
MCP and other tool frameworks are making it much easier to connect AI to enterprise systems. That is genuinely useful. But once an agent has access to CRM, ERP, documents, service management, data platforms and internal APIs, another question quickly appears.
What should each of those systems actually return for this particular task?
MCP solves an interoperability problem. It gives agents a consistent way to discover and interact with external tools and resources.
It does not solve the context problem for you.
You can expose a customer tool, but you still have to decide whether the agent should receive the customer’s full record, a selected set of attributes, a current operational view or perhaps just a yes/no answer to a very specific question.
And as we argued in the earlier MCP piece, connecting an agent to more systems can simply give it several different versions of reality if identity, state and meaning have not been resolved first.
Those are architectural choices.
They become much more important once agents start operating across several systems at the same time.
The context should increasingly be constructed, not discovered
This is probably the biggest shift for me.
A lot of agent design today is still based around discovery: give the agent tools and let it find what it needs.
For research tasks, that makes sense.
For production workflows, we will increasingly do the reverse.
The task should define the context first.
Instead of:
Agent → searches everything → decides what matters
we move towards:
Task → governed context → agent
A service agent investigating an outage gets recent deployment events, the relevant topology, live monitoring data and related incidents. It does not need every employee document that happens to mention the application name.
A procurement agent reviewing a supplier gets current supplier status, resolved identity, compliance checks, active contracts and relevant exceptions. It does not automatically need every historical document linked to that company.
A finance agent assessing a transaction gets the approved ledger state and the business rules required for that task. It does not need every operational field sitting underneath the transaction.
The agent still reasons.
It just does not have to invent the boundaries of the enterprise while it does it.
This also saves the data team from rebuilding the same logic repeatedly
There is a practical point here that gets less attention.
If every agent independently works from raw systems, every agent ends up doing some version of the same work.
Which customer record is correct? Which supplier is this? Which system owns the status? Which value is current? Which fields are sensitive? Which definition of revenue are we using?
Now multiply that by twenty agents.
That starts to look suspiciously like a new generation of integration spaghetti.
We have already looked at part of this problem in Real-Time Entity Resolution for Enterprise Data and AI. A customer, supplier or product can exist under several names and identifiers across different applications, and those duplicates become much more consequential once AI and automation begin acting on them.
If the business already knows that five records refer to the same supplier, why should every new agent have to rediscover that relationship?
The same applies to data quality, history, semantics, filtering and lineage.
That logic is reusable.
It should probably live somewhere reusable too.
Legal may actually be helping us design a better architecture
I know there is sometimes frustration with Legal and Security around AI.
Why can’t the agent just access the data? Why does every use case need another review? Why restrict information that the user can already see?
Those are fair questions.
But I think there is a useful architectural principle hidden inside the pushback.
The choice does not have to be between giving AI everything and giving AI nothing.
There is a much better middle ground:
Give the agent exactly what it needs.
That is harder to implement because it requires knowing where the information comes from, what it means, whether it is current, which entity it belongs to and which fields are actually required.
But those are largely data-engineering problems we already understand.
Agentic AI simply gives us a stronger reason to solve them properly.
If a company can say:
This agent had access to these five fields from these three systems because this task required them.
that is a much stronger answer than:
It could see everything the employee could see.
I suspect Legal will prefer that answer too.
The data layer becomes a context boundary
This is where the role of the production data layer starts to get interesting.
Historically, integration has mostly been about moving and transforming data.
For AI, there may be another job.
The data layer can help determine what representation of the business crosses into the AI environment.
That can mean synchronising current state, resolving entities, applying data-quality rules, preserving lineage, masking fields, excluding unnecessary attributes and exposing only the part of the operational estate relevant to the task.
That does not make the data layer an IAM system.
And I would not want it to.
Identity systems should still answer who is acting. Applications should still enforce their own permissions. Security systems should still determine what authority an agent has.
The data layer answers a different question:
What is the right context to give it?
That is a much cleaner separation of responsibilities.
For IOblend, this is where the independent production data layer becomes useful. The objective is not to replace the warehouse, the operational applications or the security stack. It is to make the context crossing between them and AI current, resolved, governed and reusable.
In other words, make the stack you already own easier for AI to understand without asking every agent to work out the enterprise from scratch.
Maybe we will end up with context entitlements
We already have access entitlements.
Perhaps enterprise AI eventually gives us something like context entitlements too.
An access entitlement says:
This person can read this system.
A context entitlement would say something closer to:
For this task, acting on behalf of this person, the agent may use this particular subset of information.
That would take identity, purpose, task type and data classification into account.
The broader security world is starting to ask similar questions. NIST’s work on software and AI-agent identity and authority is looking beyond simple authentication towards identification, authorization, auditing and non-repudiation as agents operate across multiple tools and datasets.
I do not think anybody has completely solved this yet.
Which is precisely why it is interesting.
The architecture we are heading towards may be much more dynamic than the traditional model where a user gets access to a system and keeps it until somebody remembers to remove it.
The agent’s useful access could depend on who asked, what they asked it to do, what information the task genuinely requires and what the agent is about to do with that information.
That is a different way of thinking about enterprise data access.
More context is not always better
For years, the direction of travel in AI has been fairly simple.
More data, more context, more tools and more capability.
Enterprise AI is starting to introduce a useful counterweight.
The best production agent may not be the one that can see the most.
It may be the one that can see exactly enough.
Enough to understand the task. Enough to make the right decision. Enough to explain how it got there.
But not enough to wander into parts of the business that have nothing to do with what it was asked to do.
That, to me, feels like the next step after least privilege.
The important question is no longer just:
What can the agent access?
It is:
What does this task actually need the agent to know?
And the more agents we connect to the enterprise, the more important that distinction is going to become.
If you are running into the same issue — trying to make agents genuinely useful without simply giving them free run of the data estate — this is something we spend a fair bit of time thinking about at IOblend. Always interested to compare notes with people dealing with it for real.
