Two clients came to us this week with almost identical requests. Both had a member of staff who had built a small internal tool using an AI assistant. Both were connecting it to the company’s Microsoft 365 account. Both just needed IT to “switch on access” so it could run properly.
In one case, the access being requested would give that tool the ability to read every email in the business. Not just the person who built it. Every inbox. Every member of staff. In the other, the tool would have been able to modify employee accounts across the entire organisation.
Neither client knew that was what they were approving.
Employee-built apps and Microsoft 365 security is fast becoming one of the most overlooked risks in UK SMEs. AI tools have made it straightforward for non-technical staff to build working software, often in an afternoon. That is genuinely useful. But when those tools connect to business systems, the level of access they request is not always what it sounds like, and it is rarely reviewed before it gets approved.
What you will learn in this post:
- Why the tools your staff are building may be requesting far more access than they need
- What “read emails” or “access user information” can actually mean at a business level
- Two questions worth asking before any new tool gets connected to your systems
- How to stay in control without blocking the initiative that makes these tools valuable in the first place
AI has made building software easy. Oversight has not kept up.
There is a growing number of people in UK businesses who are building their own tools with the help of AI assistants. They are not software developers. They are operations managers, recruiters, finance leads, and administrators who have discovered that AI can turn a business problem into a working piece of software in a matter of hours.
This is sometimes called vibe coding. The result is usually something genuinely useful. A tool that pulls data from one system and drops it into another. An automated report. A custom notification that saves someone an hour a week.
The problem is not the tool. The problem is what happens when that tool needs access to business systems.
To connect to Microsoft 365, any tool needs permission to do so. Those permissions have names. Fairly straightforward-sounding names. “Read emails.” “Access user information.” “View files.”
What those names do not tell you is the scale of what is being granted.
What “read emails” can actually mean
Depending on how a permission is set up, “read emails” can mean the tool has access to every single inbox in your organisation. Not the account of the person who built it. Every member of staff.
“Access user information” can mean the tool has the ability to reset passwords and change staff roles. “View files” can mean every document across every department, every SharePoint site, every folder in OneDrive.
These are not security flaws. These capabilities exist for legitimate reasons. Large organisations use them for compliance archiving, IT management, and security monitoring. But they were not designed with an afternoon project in mind.
According to the Nxt Gen IT team, this is one of the most consistent findings when we review what is connected to a client’s Microsoft 365 environment. Tools running with far broader access than the task they were built for would ever require.
The NCSC recommends that access to business systems should always follow the principle of least privilege: only the minimum level of access needed to do the job. Most employee-built tools do not come close to meeting that standard, not because the builder was careless, but because nobody told them it mattered.
Why nobody questions it
Staff building tools with AI assistance are not doing anything wrong. They are solving real problems. The AI helps them write the code, points them to the documentation, and suggests the permissions the tool needs. Those permissions are technically correct. They are just not always the minimum that would do the job.
Without knowing that a difference exists between “access on behalf of this user” and “access across the entire organisation,” there is no reason to push back. It works. It gets approved. And quietly, that tool now has a level of access that nobody explicitly chose to grant.
The risk rarely looks like a deliberate attack. It looks more like this: the tool was built on someone’s personal account, and when they leave the business, no one knows how to access or turn it off. Or the credentials the tool uses are stored somewhere insecure and get exposed in a breach. Or the tool runs unnoticed for two years, until something goes wrong and IT has to unpick what it was doing.
Two questions that cover most of the risk
You do not need technical knowledge to manage this well. Two questions, asked before any new tool gets connected to business systems, cover most of the risk.
Has IT seen the permission request?
Not after the tool is already running. Before. A short conversation at that point can prevent weeks of untangling later. IT can usually help the builder get the same result with a fraction of the access originally requested.
Is the tool registered under a business account or a personal one?
If it sits on a personal Microsoft account, it leaves with that person. There is also no central record of what access exists. Either of those is a problem worth avoiding.
Most of the time, the answer to both questions leads to the same outcome: the tool works exactly as intended, and the business stays in control of what it has connected to its systems.
Frequently asked questions
Should I be worried if staff are already building tools like this?
Not necessarily, but it is worth finding out what is connected and what access those connections hold. Many businesses have tools running quietly in the background that have never been formally reviewed. That is usually straightforward to sort out with the right IT support.
Do I need to stop staff from building their own tools?
No. The goal is visibility, not restriction. Staff initiative is genuinely valuable, and blocking it creates its own problems. A simple sign-off process, where any tool that connects to business systems gets a quick IT check first, is usually enough.
What does “access to Microsoft 365” actually mean for a third-party tool?
It depends entirely on the permissions granted. At one end, a tool might only be able to see one person’s calendar. At the other, it could read every email in the business or modify staff accounts. The permission name rarely makes the difference clear.
How do I find out what is already connected to our Microsoft 365 account?
Your IT team can pull a full list of every application registered against your Microsoft 365 environment, along with the permissions each one holds. If you are not sure where to start, that is a conversation Nxt Gen IT can help with.
Nxt Steps
Staff building their own tools is not a problem to eliminate. It is a capability worth managing properly.
Three things worth doing this week:
- Ask IT to review what is currently connected to your Microsoft 365 environment and what access each connection holds
- Make sure any new tool that connects to business systems goes through a quick IT check before it goes live
- Confirm that existing tools are registered under business accounts, not personal ones
None of that requires technical knowledge to ask for. And it is far easier to get right from the start than to unpick after the fact.
Explore how Nxt Gen IT can support your business. Book a call with Vinnie Itani, our resident automation and AI expert.
Related reading: When Anyone Can Build Software: Business Governance Guide
Ben helps growing businesses turn technology into a driver of performance instead of a barrier. At Nxt Gen IT he works with SME leaders, recruiters, and fast-scaling teams to design solutions that improve reliability, strengthen security, and unlock growth.
With a background in email deliverability and cloud systems, Ben specialises in making sure businesses communicate effectively, keep data safe, and get the most from Microsoft 365. His experience spans solution design, managed IT services, and virtual CIO support, always with a focus on practical outcomes that reduce headaches for business owners.
Ben has supported organisations across the UK, from recruitment agencies struggling with inbox placement to SaaS firms scaling fast, and SMEs needing a trusted partner for their IT. He believes tech is never the end goal: growth is. His role is to make sure technology never gets in the way of it.