Ask most security teams how many AI tools their organization uses and you will get a confident number. Ask them how many of those tools were approved, and the number drops. Ask which ones employees reach through a personal account, and you will often get silence. That gap is shadow AI, and it is growing faster than most governance programmes can document it.
LastPass recently made a useful argument in its post, Shadow AI Is an Identity Problem: How to Secure Unauthorized AI Access: shadow AI is, at its core, an identity problem. This note builds on that argument, adds where I think it needs qualifying, and makes the case that SaaS discovery is the right minimum viable control to start with.
A caveat on sources: the LastPass post is vendor content, and its statistics are drawn from third-party research (Akamai, Reco, Cyberhaven, IBM and others). I have not independently verified them, so read the numbers below as indicative of the scale of the problem, not as precise measurements.
What shadow AI actually is
Shadow AI is not only an employee pasting a document into a chatbot. It includes AI browser extensions with broad permissions, AI features quietly added to SaaS products you already approved, connectors and MCP servers wired to internal data, and increasingly, agents that act on a person's behalf. What they share is that they sit outside the controls the organization believes it has.
The scale reported in the LastPass post is striking. Citing Akamai research, it says nearly half of enterprise AI conversations (47.11%) happen through personal rather than corporate credentials. Citing Reco, it says around 80% of employee AI tools, including extensions and MCP connections, operate outside IT oversight. And citing Infosecurity Magazine, it notes that 82% of respondents discovered unknown agents in the past year. Whatever the exact figures in your environment, the direction is consistent: your inventory is incomplete.
Why bans do not work
The instinctive response is to block the tools. It rarely holds. Employees have a real productivity reason to use AI, and the tools are one browser tab away. A blanket ban pushes usage onto personal devices, personal accounts and networks you cannot see, which makes the risk larger and the visibility worse. Governance that depends on people not wanting to use useful tools is not governance.
The workable alternative is the one security teams already apply to other risks: see what is happening, decide what is acceptable, offer a sanctioned option, and enforce at the point of use.
Why identity is the right lens
Most shadow AI begins at a login. Someone signs up with a personal email or a free tier, bypassing single sign-on, conditional access, and the offboarding process. From that moment the organization has data flowing into an account it does not own, cannot audit, and will not close when the person leaves.
Agents sharpen the point. An agent typically inherits the permissions of the human who deployed it. If you cannot see and govern the human identity and its access to AI and SaaS applications, you have no foundation for governing the agents that act through it. Agent governance is built on human identity governance, not in place of it.
That reframes the first question. Before asking what data an AI tool can see, ask which identities are reaching which tools, and with which credentials.
The minimum viable control: discover first
A minimum viable control is the smallest thing you can deploy that materially changes your position and gives you something to build on. For shadow AI I argue that is continuous SaaS discovery tied to identity, and this is where LastPass SaaS Monitoring earns its place.
- It works where the signal is. Monitoring runs in the browser extension, so it observes the login event itself, including sign-ins made with personal credentials, which is exactly the blind spot SSO logs and network tools miss.
- It builds the inventory without a survey. Instead of asking departments what they use, you get an always-current list of approved and unapproved applications, with no manual IT effort.
- It is cheap to start. Where a password manager extension is already deployed, discovery does not require a new agent, a network change, or a procurement cycle. Per the vendor, it is included in LastPass Business Max.
- It surfaces waste as well as risk. Flagging applications unused for 30 days helps retire abandoned accounts and licences, which gives the business a reason to support the programme.
- It leads naturally to enforcement. The companion SaaS Protect lets an administrator set each application to Allow, Warn or Block, and the Warn state can redirect people to a sanctioned alternative. That graduated approach is far more realistic than an immediate ban.
The sequencing matters. Visibility first, policy second, enforcement third. Teams that start with a block list are guessing; teams that start with discovery are deciding from evidence.
What it does not do
A control described as minimum should be honest about its limits. SaaS discovery in the browser is not a complete answer, and I would not present it as one:
- Coverage follows the extension. Unmanaged browsers, unmanaged devices and native mobile apps sit outside what a browser-based tool can observe.
- It tells you which tool is used, not what data was shared. It is not a data loss prevention control, and it does not classify prompts or files.
- It does not see agent-to-agent or server-side traffic, such as MCP connections that never touch a user's browser.
- Discovery is not remediation. The inventory only helps if someone owns the review, the decision and the follow-up.
These gaps are the reason it is a starting point rather than the whole programme. Enterprise browsers, network and cloud access controls, and DLP address the layers discovery cannot, and the better vendors, LastPass included, position themselves as complementary to them rather than as a replacement.
A practical first 90 days
- Days 1 to 30: deploy discovery in observe-only mode. Do not block anything yet. Collect the inventory, including personal-credential logins and AI browser extensions.
- Days 30 to 60: triage. Classify applications as sanctioned, tolerated or unacceptable, based on the data they touch and the vendor's terms. Review AI features added to approved SaaS products in the last six months.
- Days 60 to 90: act. Publish an AI usage policy, name a sanctioned alternative for each common use case, move key apps to Warn, and block only the clearly unacceptable ones, with an explanation at the point of access.
- Throughout: add AI accounts to your offboarding checklist, and keep a register of agents with a named human owner for each.
Four questions make a useful governance test. Can you detect AI logins made with personal credentials? Have your approved SaaS tools added AI features recently? Do you know which AI extensions are installed? Does offboarding cover AI accounts? If any answer is no, discovery is where to begin.
The bottom line
Shadow AI will not be solved by prohibition, and it cannot be governed while it is invisible. Treating it as an identity problem points to the right first move: find out who is using which tools, with which credentials, and do it continuously. SaaS discovery of this kind does not finish the job, but it is the smallest control that changes what you know, and every later decision about policy, data and agents depends on it.
If you would like help assessing your shadow AI exposure or writing an AI usage policy, get in touch through the consultation form.