You find out someone on the team has connected an AI tool to their work account.
Maybe it is reading documents. Maybe it can see calendar events. Maybe it has access to email. Maybe nobody is quite sure what they clicked.
The worst response is usually panic.
The best response is to work out what was connected, what the tool can actually access, what it has already been given, and whether that access should continue.
For a small business, this does not need to become a six-week governance project. You can get a useful first picture surprisingly quickly.
Start with the account, not the AI
Ask the employee to show you exactly what they connected.
You want the boring details:
- the name of the AI product
- whether it is a personal or company-managed AI account
- which work account they signed in with
- which services they connected, such as Google Drive, Gmail, Microsoft 365, Slack, GitHub or another business system
- what permissions were shown on the consent screen
- whether the AI can only read information or can also create, edit, send, delete or share it - broader action permissions deserve the same caution described in our guide to AI agents with too much power
- whether they uploaded or pasted any sensitive information before you noticed
Do not begin with "What have you done?"
Begin with "Show me the connection."
That gets you facts instead of guesses.
Work out what the connection can reach
Connecting an AI tool to a work account can mean very different things.
At one end, an app may receive only basic sign-in information such as a name and email address.
At the other, it may be authorised to read files, search mail, access calendars or take actions inside business systems.
The important question is not simply whether the employee "connected Google" or "connected Microsoft". It is which permissions the app was granted.
Google Workspace administrators can review third-party apps, the users accessing them, the Google services requested and the OAuth scopes an app uses. Google also lets administrators classify apps as Trusted, Limited, Specific Google data or Blocked.
Microsoft Entra similarly gives organisations controls over when users may consent to application permissions.
Browser extensions are a different kind of connection and deserve a separate check. An AI extension may request permission to read or change pages you visit, access browsing data or interact with specific websites. In a managed Chrome environment, administrators can control which extensions users may install and can block extensions that request permissions the organisation does not allow. If the AI tool arrived as a browser extension rather than a normal connected app, review the extension's permissions and your browser-management controls as well as OAuth access.
You do not need to memorise OAuth terminology. You just need to establish the practical boundary:
What can this app see, and what can it do?
Check what data may already have been exposed
Permissions tell you what an app could access.
They do not necessarily tell you what it did access.
Ask the employee what they used the tool for.
Did they:
- search company Drive or OneDrive?
- ask it to summarise client documents?
- connect their mailbox and search old conversations?
- upload contracts, HR material or financial files?
- paste API keys, passwords or credentials?
- ask it to analyse customer or employee personal information?
The answer determines what happens next.
If they connected an app but never used it with sensitive information, the issue may simply be an unapproved integration that needs reviewing.
If confidential, personal or regulated information was actually shared, you may need a more formal internal review.
The ICO's AI and data protection guidance makes clear that organisations still need to consider their data-protection responsibilities when AI systems process personal data. The fact that an employee used an AI tool does not make those responsibilities disappear.
If the tool is not approved, contain first
If you do not recognise the product, cannot establish what it does, or know that it should not be connected to work systems, disconnect it while you review.
For many cloud services, removing access involves revoking the application's authorisation from the work identity or admin console, not merely closing a browser tab or promising not to use the tool again.
If the employee pasted a password, API key, recovery code or other live credential into the AI service, treat that credential as exposed and rotate or revoke it through the normal security process.
Do not assume changing the AI password fixes a compromised business credential. They are separate things.
If the employee only granted read access to a low-risk folder and no sensitive information was used, the appropriate response may be much lighter.
The point is to match the response to what actually happened.
Do not punish curiosity
This matters more than it sounds.
Employees often connect AI tools because they are trying to get work done faster, not because they are trying to bypass security.
If the first person who admits using an unapproved tool gets publicly blamed, the next person may simply keep quiet.
That gives you less visibility, not more security.
A much more useful question is:
What problem were you trying to solve?
You may discover that five people are independently using different AI products to solve the same repetitive job.
That is useful information. It gives the business an opportunity to choose an approved tool, provide a safer account or build a clearer workflow.
The NCSC's September 2026 guidance on shadow AI makes the same point from the employee side: organisations that understand why staff are using unapproved AI tools are better placed to identify the risks, provide secure alternatives and support useful innovation. That is a better outcome than simply driving experimentation underground.
Decide whether the tool is actually useful
Do not automatically ban it just because nobody approved it first.
Review it.
Ask:
- Does it solve a real business problem?
- Is there an approved tool that already does the same job?
- Does the provider offer a business or managed account?
- Can access be narrowed?
- Can risky actions require approval?
- Can administrators see who has connected it?
- Is there useful logging?
- Are the provider's data-handling terms acceptable for the information involved?
The result may be:
No, remove it.
Or:
Yes, but use the company account and restrict what it can access.
Or even:
This is genuinely useful. We should standardise it for the team.
Security review is not supposed to eliminate useful technology. It is supposed to make the risk visible enough to make a sensible decision.
Look for the same connection elsewhere
One employee finding a useful AI product often means others have found it too.
Check whether the same application appears elsewhere in your organisation's connected-app or third-party access controls.
Google Workspace, for example, provides an Accessed apps view showing third-party applications that have accessed Google data and the users associated with them. Google notes that some app-access details can take time to appear, so a newly authorised app may not show immediately.
If you use Microsoft 365, your Entra application and consent controls can provide a similar starting point for understanding app permissions.
For very small teams without centralised identity administration, you may need to ask people directly and keep a simple list.
A spreadsheet containing Tool / User / Work account / Connected systems / Approved? / Owner / Review date is already much better than having no idea what is connected.
Turn the surprise into a simple rule
Once you understand the incident, fix the process that allowed the uncertainty.
You do not need a 40-page AI policy.
A small business can start with something like:
Before connecting a new AI tool to company email, files, calendars, code, customer systems or other work data, ask for approval and show what access the tool is requesting.
Then define who gives that approval.
That person does not have to be a full-time security specialist. In a small company it might be a director, technical lead or external IT provider.
The important thing is that someone owns the decision.
Add technical controls where they make sense
Training and policy help, but some platforms also let you reduce the number of decisions individual users have to make.
Depending on your systems and licence level, you may be able to:
- restrict unapproved third-party applications
- allow only approved OAuth scopes
- require administrator approval for higher-risk permissions
- review which apps users have authorised
- revoke access centrally
- separate personal AI accounts from company-managed accounts
Google Workspace and Microsoft Entra both provide controls in this area.
Use them proportionately. A three-person company does not need to recreate the identity architecture of a bank.
But if your staff can connect any third-party app to years of company email and files without anyone noticing, a little more control may be worthwhile.
What if sensitive information was involved?
If personal data, client confidential information, credentials, regulated records or commercially sensitive material was actually shared, treat that as a separate question from whether the app itself is approved. Our guide to deciding what you can paste into AI gives a useful starting point for classifying that information.
Work out:
- what information was involved
- whose information it was
- which service received it
- which account and plan were used
- whether it was uploaded, pasted or accessed through a connector
- what the provider says about retention and use for that product - see what happens to your data after you send it to AI for the wider data-handling questions
- whether any contractual, regulatory or internal reporting requirements apply
If the potential impact is significant or you are uncertain about your obligations, involve the appropriate privacy, legal, security or client-contact person rather than trying to solve it from an AI settings screen.
The 15-minute version
If you discover an employee has connected an AI tool and need a quick first response, do this:
- Identify the exact AI product and account.
- List the work services it is connected to.
- Read the permissions it was granted.
- Ask what work data has actually been used with it.
- Disconnect or revoke it if the access is unapproved or unclear.
- Rotate any credentials that were pasted into the tool.
- Check whether anyone else has connected the same app.
- Decide whether to ban, restrict or formally approve the tool.
- Write down one simple approval rule for future AI connections.
That is enough to turn "somebody connected something" into a situation you can actually assess.
The bigger lesson
Shadow AI is often treated as an employee problem.
Usually it is also a visibility problem.
If people are experimenting with AI at work, the business needs a lightweight way for them to do that without guessing where the boundaries are.
The goal is not to make employees afraid to try new tools.
It is to make sure that when an AI product asks for access to company data, someone understands what is being granted before the answer is simply "Allow".