Your AI Tools Have Logins Now, and Nobody Is Managing Them
AI agents connect to email, files, and CRM with real credentials that outlive the employee who created them. How to inventory and govern non-human identity.
The short answer
AI tools connect to your systems through OAuth grants that persist across password changes, are often broader than the task requires, and frequently outlive the employee who authorized them. Most small businesses estimate five to ten connected applications and actually have dozens. Restricting user consent closes most of the exposure.
For twenty years, identity management in a small business meant one thing: employees have accounts, and when an employee leaves, you disable the account. That model is now incomplete in a way that creates real exposure.
AI tools do not just answer questions anymore. They connect. A meeting assistant joins calls and stores transcripts. A sales tool reads and writes to your CRM. A scheduling agent has calendar and mailbox access. Each of those connections is an identity with permissions, and almost none of them are in whatever system you use to track access.
How these connections get created
The mechanism is usually OAuth. An employee clicks a button in a third-party tool, sees a Microsoft or Google consent screen, clicks accept, and grants that application ongoing access to their mailbox, their files, or their calendar.
Three properties of that grant matter.
It persists. The grant survives password changes and, depending on configuration, it survives multi-factor challenges. It is a standing authorization, not a session.
It is often broader than the task requires. A tool that needs to read your calendar frequently asks for read and write access to mail as well, because the developers wanted flexibility.
It usually outlives the employee. When you disable a departing employee's account, the app-level grants attached to that identity may or may not be revoked depending on your platform and configuration. Service accounts and workspace-level installations survive regardless.
The inventory nobody has
Ask an owner of a 60-person company how many third-party applications have standing access to their tenant. The estimate is usually five to ten. The actual count, when we pull it, is regularly in the dozens, and the list includes tools from vendors nobody at the company currently uses.
Pulling that list takes about twenty minutes. In Microsoft 365 it is under Enterprise Applications in Entra. In Google Workspace it is under Security, then API Controls, then App Access Control. Export it and sort by permission scope, not by name.
You are looking for anything with mail read, mail send, files read-all, or directory read permissions. Those four scopes cover most of what an attacker would want.
Why "mail send" is the one to worry about
An application with permission to send mail as your users can send mail as your users. It does not need to steal a password, and it does not trip a login alert, because it is not logging in.
The attack pattern that follows is straightforward and we have seen versions of it locally. A legitimate-looking productivity app gets consent from one employee. It uses mail access to read the thread history, learns how your team writes and who approves payments, and sends a message from a real internal address at a plausible moment. Nothing about the message is technically forged. It is coming from your tenant, through an authorization somebody granted.
Practical controls, in order of value
Turn off unrestricted user consent. In both major platforms you can require administrator approval before users grant an application access to company data, or restrict consent to a list of verified publishers and low-risk permission scopes. This one change closes most of the exposure.
Build the request path at the same time. If asking for approval takes three weeks, employees will find tools that do not require it. Commit to a response within a few business days and staff it.
Review the existing grants and revoke what nobody uses. Set a recurring quarterly review. Twenty minutes.
Inventory service accounts and API keys separately. These are the ones with no human owner and no expiry, sitting in an automation somebody built two years ago. Every one needs a named owner, a documented purpose, and a rotation date.
Include non-human identity in offboarding. When an employee leaves, check what they authorized, not just what they logged into.
The part that is coming
Agentic tools, which take actions rather than producing text, make all of this considerably sharper. An agent that can send email, move money, or modify records is functionally an employee with credentials and no judgment about social engineering. The governance question is not whether the model is good. It is what the agent is permitted to do, who approved it, and what the second signature is on actions above a threshold.
Small businesses that already have a clean identity inventory will handle that shift easily. The ones that do not have a list at all will find out what is connected during an incident.
Get the register
The Non-Human Identity Register is a workbook for tracking every OAuth grant, service account, API key, and integration in your environment: owner, purpose, permission scope, risk rating, last review date, and rotation schedule. It includes the export instructions for both major platforms and a risk scoring column that flags the high-permission grants automatically.
Fill it in once and it becomes a quarterly twenty-minute task instead of an archaeology project.
Frequently asked questions
What is non-human identity in cybersecurity?
Any credential-holding identity that is not a person: OAuth grants to third-party applications, service accounts, API keys, integration users, and AI agents. These have permissions, persist independently of employee accounts, and are usually absent from whatever system a small business uses to track access.
How do I audit OAuth app permissions in Microsoft 365?
Open Microsoft Entra and go to Enterprise Applications, then export the list and sort by permission scope rather than by name. You are looking for anything holding mail read, mail send, files read-all, or directory read permissions. In Google Workspace the equivalent is Security, then API Controls, then App Access Control.
Why is mail send permission dangerous?
An application with permission to send mail as your users can do so without stealing a password and without triggering a login alert, because it is not logging in. The resulting message comes from a real internal address through an authorization somebody granted, so nothing about it is technically forged.
What is the single most effective control for AI app access?
Turn off unrestricted user consent so employees cannot grant a third-party application access to company data without review. Pair it with an admin approval request path that answers within a few business days, because if asking takes three weeks people will find tools that do not require it.
Related reading
- The Voice on the Phone Is Not Your CFO
- MFA Stopped Being Enough About Two Years Ago
- The Microsoft 365 Settings Most Phoenix Businesses Never Turned On
- Anyone Can Send Email as Your Company Until You Fix This
- Your Weakest Security Control Belongs to Somebody Else
- Offboarding an Employee in 60 Minutes