For years, enterprise security has been built around a fairly straightforward model: authenticate a person, determine what that person is allowed to access, and give them the tools to do their job.
AI agents complicate that model.
If I have access to ten projects, three databases and several business applications, should an AI agent acting on my behalf automatically inherit all of those permissions?
I don’t think it should.
As AI moves from answering questions to actually using software, companies need to distinguish between two things that can look deceptively similar: giving an AI permission to act for someone and giving it the same access as that person.
Those are not the same requirement.
Humans have broad access but use narrow context
Think about how people actually work.
A senior employee may technically have access to customer data, financial systems, analytics platforms and internal documents. But when investigating why ecommerce sales dropped last week, they probably need only a small portion of that information.
Humans naturally narrow their attention to the task.
Software doesn’t necessarily do that unless we design the boundary for it.
This becomes increasingly important as AI agents gain the ability to query databases, call APIs, execute code and move between applications.
The question is no longer simply, “Can this user access the system?”
It becomes, “What does this agent need access to for this particular job?”
What we learned from connecting Stormly through MCP
We face this question directly at Stormly, where we build AI-powered analytics for ecommerce businesses.
Through our MCP connector, users can connect an AI client to a Stormly project and work with their analytics data from the AI environment they already use.
For example, someone might ask:
“Why did sales drop last week?”
Instead of requiring that person to open an analytics application, find the right reports and manually investigate the change, the AI can work with Stormly to analyze the relevant data.
But there’s an important security decision behind that convenience.
We scope MCP access to a specific Stormly project.
Connecting an AI client shouldn’t mean giving it an open door to everything available across the platform. It should get the context required to complete the task.
That is essentially the old principle of least privilege applied to a new kind of software user.
Authentication is only the beginning
One mistake I think companies will make with AI agents is focusing heavily on authentication.
Authentication matters. You need to know who authorized the connection.
But authentication answers only one question:
Who are you?
It doesn’t answer:
What should this agent be allowed to do?
An authenticated employee might legitimately have access to multiple customer projects. That doesn't automatically mean every AI session they start needs access to all of them.
Authorization should therefore become more contextual.
Which project is the person working on?
Which tools does the agent need?
Which data does the task require?
Can the agent read information, modify it, or both?
And can that permission be revoked without affecting the user's own access?
Those questions become more important as agents move from retrieving information to taking actions.
More context isn’t always better
There is a common assumption in AI development that more context produces better results.
From a model-performance perspective, additional relevant context can certainly help.
From a security perspective, “give the AI everything” is a terrible default.
If an agent needs product views, transactions and customer behavior to investigate a conversion decline, giving it unrelated projects or data doesn't necessarily improve the analysis. It simply increases the amount of information exposed if something goes wrong.
The goal should be sufficient context, not maximum context.
At Stormly, this also affects how we think about building AI itself. An agent doesn't need to know everything upfront. It needs access to the right tools so it can retrieve the information necessary for the question it's investigating.
That creates a much cleaner boundary.
Think of AI access as delegation
I find it useful to think about AI agents the same way we think about delegating work to another person.
If I ask someone to investigate one customer account, I don't hand them every password I possess.
I give them what they need for that assignment.
AI should work the same way.
Before connecting an agent to a business system, I think technology leaders should be able to answer five questions:
- Who authorized this agent?
- Which resources can it access?
- Which actions can it perform?
- How long does that access last?
- Can we determine afterward what it actually did?
If those answers are unclear, the agent probably has too much implicit trust.
AI makes old security principles more important
AI agents introduce new technical challenges, but I don't think the solution requires abandoning everything we already know about security.
Quite the opposite.
Least privilege, clear authorization boundaries, scoped credentials and auditability become more important when software can operate autonomously and at machine speed.
An overly broad permission granted to a person may sit unused for months.
Give the same permission to an agent capable of exploring systems automatically and the consequences can be very different.
That's why I think one of the most important questions for companies adopting AI agents isn't:
“What can we connect our AI to?”
It's:
“What is the minimum this agent needs to know and do to complete this particular task?”
AI becomes more valuable when we give it the ability to act.
But the more capable agents become, the more deliberate we need to be about where that ability stops.