Shadow AI in 2026: From Chatbots to Agents, and What to Check First
In 2023, "shadow AI" meant something fairly simple: an employee pasting a paragraph of confidential text into a public chatbot to get work done faster. The risk was data leaving the company. The usual answer was a policy memo and a blocked website.
The security practitioner Anton Chuvakin recently revisited the topic in a LinkedIn post and a longer field guide, Seven Shades of Shadow AI. His conclusion is that the risk has moved "from passive data leakage to active, autonomous rogue actions". This article summarises what has changed and sets out the first checks an organization can make.
The problem has moved
Personal chatbot accounts have not gone away, but they are no longer the whole picture. Shadow AI now also arrives in ways nobody in the organization consciously chose:
- AI inside software you already approved. A vendor adds an AI assistant to a SaaS product you reviewed years ago, and it is on by default or a workspace administrator switches it on. It runs on the same domain as the product, so a web filter cannot separate the two.
- Coding assistants and their connections. Developers run AI coding agents on personal subscriptions or keys, sometimes connected to internal databases, systems and a command line, with the developer's own permissions.
- AI built into your own applications. A quick feature calls an external AI service, occasionally with a key that started on someone's laptop.
- Agents acting as employees. Assistants connected to a mailbox, chat or the CRM can read, send and change things with the full access of the person who connected them.
- Automations nobody owns. Workflow agents built for a project keep running on shared service accounts long after their creator has moved on.
The common thread is that a chatbot talks, while an agent acts. A shadow chatbot can leak what someone types into it. A shadow agent can also send the email, update the record or run the command.
Not all shadow AI carries the same risk
Chuvakin makes a point that deserves more attention: much everyday shadow AI is low risk. Using a personal account to polish a public announcement is not the same as connecting an unapproved agent to a production database. Treating both with the same blocks and warnings costs security teams credibility and pushes AI use further out of sight.
He suggests sorting each case by four questions, which we paraphrase here: who switched it on, whose identity it runs as, whether it only talks or also acts, and where you would be able to see it. His shorthand for the agent cases is "Shadow Agent Risk = Reach x Agency": what the tool can reach, multiplied by what it is allowed to do on its own.
Five checks to start with
- Find out what is in use. Build an inventory from evidence, not memory: single sign-on and app consent records, expense and card data for AI subscriptions, and network logs for AI services. Include personal accounts used for work.
- Review AI settings in your core SaaS tools. Decide, tenant by tenant, which AI features stay on, which are restricted and which are switched off. Treat a vendor's new AI feature or new AI subprocessor as a trigger for a short review.
- Look at the permissions, not just the tools. List the AI apps and connectors that employees have authorised and what each one may read and change. Require administrator approval for high-impact access, such as a full mailbox or an entire file store.
- Give every acting agent its own identity and an owner. An agent that can send, change or delete should not run on an employee's personal login or a shared key. Its own narrowly scoped identity lets you see it, limit it and switch it off without locking out the person behind it.
- Make the approved path better than the workaround. People use unapproved tools because they help. Offer an approved tool for the common use cases and a request process quick enough that nobody needs to route around it.
Then review on a schedule. An assistant approved last quarter may have gained new connections since, and an agent whose owner has left should be retired.
Where blocking fits
Blocking public AI websites remains a reasonable control on managed devices and networks. It does not reach AI features inside approved SaaS, tools running locally on a laptop, or personal devices. Blocking is one control among several, chosen case by case once you know what is actually in use.
How NoéMI Phase 0 approaches it
Every Project NoéMI engagement begins with Phase 0, the AI readiness questionnaire, together with a free security audit that is included and runs alongside it. The questionnaire asks what AI is already in use, whose access it runs on and what it can change. The audit gathers the evidence with read-only checks: consented AI apps and their permissions, AI settings in core SaaS tenants, AI tools on managed endpoints, and AI service keys in code and configuration.
The outcome is an inventory sorted by what each item can reach and do, with a clear recommendation for each: keep it, move it onto a governed path, narrow its access, or switch it off. An agent acting on personal or shared credentials with no owner is treated as a gap to close before a pilot begins. The aim is not less AI. It is AI the organization can see, trust and account for.
A practical next step
If you would like a structured view of the AI already running in your organization, the NoéMI Phase 0 AI readiness questionnaire is a good place to start. The free security audit runs alongside it.
Sources
- Anton Chuvakin, LinkedIn post on shadow AI: https://www.linkedin.com/posts/chuvakin_remember-when-shadow-ai-just-meant-an-employee-share-7523801757739728896-Pa3w/
- Anton Chuvakin, "Seven Shades of Shadow AI: A 2026 Field Guide for Pragmatists", Anton on Security (Medium): https://medium.com/anton-on-security/seven-shades-of-shadow-ai-a-2026-field-guide-for-pragmatists-76c76d3c984e