# How shadow AI examples expose hidden company risk > These shadow AI examples show where unsanctioned tools hide, what evidence they leave, and how to find them without driving employees underground. Shadow AI rarely arrives as a dramatic security breach. It arrives as a browser extension that rewrites sales emails, a personal chatbot account used to summarize a contract, or an AI feature switched on inside software the company already bought. By the time leadership asks for an inventory, staff may have sent company data through dozens of tools that procurement, IT, and security have never reviewed. The useful response is not a bigger acceptable-use policy. A company needs to find the tools, learn what data crosses each boundary, and give people an approved way to get the same job done. Blanket bans produce cleaner policy documents and worse evidence. A practical discovery program treats employees as witnesses to a broken buying process, not suspects in an interrogation. I have seen teams spend weeks debating an AI policy while the meeting recorder, support desk, design suite, and individual browser profiles kept sending data to models. The argument was happening one layer above the actual work. Inventory comes first because nobody can govern a data flow they cannot name. This article uses shadow AI to mean AI used for company work without the review, ownership, and controls the company requires. That definition covers more than unapproved chatbots. It also catches approved software whose AI feature escaped the original review, which is where many inventories fail. ## Shadow AI is a control gap, not a product category A tool becomes shadow AI when company use outruns company oversight. The same chatbot can be approved for a marketing team, prohibited for legal documents, and completely unknown when an engineer accesses it through a personal account. Product names do not determine the risk. The account, data, configuration, contract, and business purpose do. Three conditions often get blurred. An unsanctioned tool has no company approval. An unmanaged tool may be approved in principle but lacks a company account, configured retention, access review, or named owner. An embedded AI feature lives inside an approved vendor and may activate after the vendor review. Treating all three as the same creates bad remedies. Procurement can replace an unsanctioned subscription, IT can bring an unmanaged account under company control, and the vendor owner must review an embedded feature. The consequence of that distinction is practical. If security sends a list of forbidden product names, it will miss a writing assistant added tomorrow and will wrongly flag an approved enterprise tenant. Record the data flow instead: who uses the capability, for what task, under which identity, with which input, and where the output goes. Those facts survive product rebranding. NIST AI Risk Management Framework 1.0 organizes work around Govern, Map, Measure, and Manage. The useful lesson here is sequence. A company cannot measure or manage a use case that it has not mapped, and mapping without an owner leaves a spreadsheet that decays. A shadow AI inventory therefore needs both evidence and responsibility from its first day. I would not start by arguing whether a feature contains a true model, a rules engine, or marketing dressed as AI. If it accepts company information and produces or acts on a probabilistic result, put it in the discovery queue. Technical classification can happen during review. Missing a data flow because a vendor chose vague language is the more expensive error. ## Browser extensions hide beside ordinary work Browser extensions are the easiest shadow AI examples to install and among the hardest for a manager to see. They sit inside the tool employees already use all day, can read page content under broad permissions, and may send selected text or whole pages to an external service. A useful extension can become a company-wide data path after one colleague shares it in chat. Look beyond extensions with AI in the name. Writing assistants, transcription tools, search helpers, screenshot utilities, sales prospecting add-ons, PDF summarizers, and coding helpers may all call models. The store description is weak evidence because capabilities and ownership can change after installation. The installed version, requested permissions, service domain, account type, and observed traffic tell you more. Managed browser inventories are the cleanest source when the company controls browsers. Export extension identifier, name, version, install source, requested permissions, device, browser profile, and last-seen time. On a sample device, `chrome://policy` or `edge://policy` shows whether extension policies actually reached the browser. A policy that exists in an admin console but not on endpoints is an intention, not a control. Unmanaged profiles need a different approach. Ask employees to open the extension page during a short, announced review and report work-related add-ons. Pair that declaration with privacy-reviewed DNS or proxy domain summaries if the company already collects them. Do not install invasive monitoring simply to run an AI inventory. The surveillance cost can exceed the information gained, especially on personal devices. The awkward case is an extension approved for harmless public text that later touches a customer record, private repository, or unreleased financial plan. Permissions describe what the extension can access, not what staff actually send. Interview at least a sample of users about real prompts and pages. A permissions-only audit will overstate some risks and miss the dangerous workflows that happen through copy and paste. For each extension, preserve evidence before removing it: identifier, publisher, permissions, account email, billing owner, example task, data types, and last use. Removal without a record makes recurrence look like a new problem and prevents the company from finding colleagues who still depend on the workflow. ## Personal accounts turn company data into private history Personal AI accounts hide because company identity systems cannot see them. An employee may use a consumer chatbot with a private email address, sign in through a personal social account, or pay with a personal card and expense the charge under software or research. Normal single sign-on reports will show nothing. The data path is wider than a prompt box. People upload spreadsheets, paste support conversations, attach contracts, share screenshots, and keep generated output in private history. They may also build saved assistants or reusable projects that retain instructions and reference files. When the employee leaves, the company may lose both visibility and the useful work product while the external account still holds its history. Expense data is one discovery source, but it misses free plans and subscriptions employees do not claim. Search approved expense categories for vendor names and generic descriptors, then ask finance to flag recurring small software charges for review. Do not treat a reimbursement as proof of misconduct. Many employees pay personally because the approved purchasing route takes longer than the task can wait. Identity evidence works by absence. If a team openly uses an AI service but the service does not appear in single sign-on, the company password manager, procurement records, or managed browser bookmarks, ask which accounts hold the work. Company email logs may show verification messages or shared outputs, subject to existing privacy and employment rules. Use those clues to open a conversation, not to auto-convict a person. A personal account is not automatically unsafe, and an enterprise label is not automatically safe. Review whether prompts train a provider's models, how long content remains, whether administrators can delete it, where subprocessors handle it, and whether contractual terms match the data. The correct decision may be to move the workflow into a company tenant, restrict its inputs, replace the tool, or stop the use. The fastest way to surface personal use is to offer amnesty during a time-boxed inventory. Tell staff that disclosure will not trigger discipline unless they conceal known harm or continue a prohibited flow after review. People will report the tools that save them time when they believe the company wants to preserve the benefit. Without that assurance, they will report only what IT already knows. ## Embedded vendor AI bypasses the old approval An approved vendor can create shadow AI after procurement ends. Customer support platforms add reply drafting, meeting tools add transcription and summaries, design suites add generation, CRM systems add scoring, and office suites add assistants. The base product may have passed review years before the AI feature existed. This category escapes inventories because finance sees no new vendor and identity systems see no new application. The feature may be enabled by default, offered as a trial, switched on by a workspace administrator, or activated by an individual user. A contract renewal can quietly change data terms or add a model provider without creating a new security ticket. Start with the systems that hold concentrated sensitive data: source code, customer messages, sales records, employee records, contracts, financial plans, recordings, and production telemetry. Ask each business owner for the current feature list and administrator settings, not the document approved at purchase. Compare those settings with release notes, order forms, data-processing terms, and subprocessor notices that the company already receives. The review must distinguish data used to deliver the feature from data used to improve a shared model. It must also identify what the feature reads automatically. A meeting assistant that processes every recording creates a different exposure from a user who submits one selected transcript. A CRM scorer that reads the whole account history differs from a drafting tool fed one paragraph. Do not accept disabled by default as a permanent answer. Record who can enable the feature, whether that action produces an admin event, and whether tenant administrators can detect individual activation. If nobody checks the event, a toggle is only a speed bump. If the vendor gives no useful event, schedule a setting review and tell the vendor owner what evidence to retain. Procurement questionnaires also need a trigger for material feature changes. The vendor owner should reopen review when AI begins processing a new data class, takes automated action, uses another provider, changes retention, or removes an administrative control. A yearly vendor review is too slow for software that ships features every week. ## Connectors and API keys create a larger blast radius AI connected to company systems deserves faster review than a standalone prompt tool because it can read continuously or act without another copy-and-paste step. OAuth grants, API keys, personal access tokens, webhooks, workflow automations, and agent connectors can expose mail, files, calendars, code, ticket queues, or customer records. These uses often begin as experiments. An engineer creates an API key for a weekend prototype. A salesperson connects an assistant to a calendar. An operations lead adds a model step to an automation platform. The prototype becomes a shared workflow, but the credential remains tied to one person and nobody sets spend limits, rotates secrets, reviews scopes, or owns failure handling. Search the control planes that already record access. Identity providers list OAuth grants and consented scopes. Source control systems list installed applications and tokens. Cloud secret stores, CI/CD variables, automation platforms, password managers, and expense systems reveal other pieces. Repository secret scanning can find accidentally committed keys, but it cannot find a correctly stored key used for an unapproved purpose. Scope names require interpretation. Read access to files may mean one selected file or every file the user can reach. Offline access may let a service continue after the browser session ends. A connector using an employee's broad permissions can inherit years of accidental access. Ask what the connector needs for the task, then create a dedicated identity or narrower scope where the platform supports it. Also inspect outputs and actions. A summarizer that posts into a public channel can leak data even if its model provider handles inputs correctly. An agent that drafts but waits for approval has a different failure mode from one that sends messages, edits records, or deploys code. Inventory read, write, approval, and destination separately. Calling everything an integration hides the decision that matters. Revoking an unknown token immediately can break a customer-facing workflow. First identify the owner and dependent process, unless active harm requires containment. Then move the credential under company ownership, reduce scope, document the data flow, and create a safe shutdown path. Security gains nothing by turning a hidden dependency into an outage. ## A blanket ban destroys the evidence you need A total ban sounds decisive, but it usually moves AI use into personal browsers, phones, and accounts. Employees still face the workload that drove adoption, while the company loses logs, contract terms, and a chance to shape the workflow. The policy reduces reported use, not actual use. The recommendation stays popular because leaders can announce it quickly and measure acknowledgements. It also gives legal and security teams a clear sentence while they build a better program. As a temporary pause on high-risk data or autonomous actions, a narrow ban can be sensible. As the operating model for ordinary drafting, research, translation, and analysis, it creates an incentive to hide. Replace one broad prohibition with boundaries staff can apply during real work. State which data classes never enter an unreviewed tool, which low-risk tasks employees may test, which actions always need human approval, and where to request a company account. Name examples drawn from actual company systems. Abstract labels such as confidential often fail because a support agent and an engineer classify the same pasted text differently. Give the request route a response time and an owner. If a low-cost tool waits six weeks for review, people will route around the process. A short form should capture purpose, users, data classes, account type, integrations, output destination, and urgency. Security, privacy, legal, procurement, and the business owner do not need to review every case at the same depth. Triage low-risk uses quickly and reserve the full review for sensitive data or actions. Approved alternatives matter more than warnings. If staff use a personal summarizer, an instruction to stop is incomplete until the company offers an approved summarizer or changes the work. Preserve the employee's task description during review. It may expose a process problem that deserves automation even when the chosen tool fails the risk test. Measure disclosures, migrations to managed accounts, removed risky connections, and time to decision. Do not celebrate a falling number of reported tools unless other evidence falls too. A sudden clean inventory after a punitive message usually means the reporting channel failed. ## Discovery works as a repeatable evidence cycle A useful shadow AI discovery method combines declarations, technical evidence, commercial records, and workflow interviews. No source covers the whole company, so the process reconciles several incomplete views and records how confident the team is in each finding. Run the first pass as a defined project, then repeat the evidence collection on a schedule. 1. **Set the scope and amnesty.** Name the business units, devices, data classes, and review window. Tell employees that the goal is to bring useful work under company control. Provide examples such as personal chatbots, browser add-ons, meeting summaries, vendor AI toggles, model APIs, and connected agents so people do not report only obvious chat tools. 2. **Collect evidence already held.** Export managed browser extensions, single sign-on applications, OAuth grants, installed source-control applications, expense vendors, automation steps, approved vendor lists, and workspace AI settings. Use existing lawful telemetry. Record the collection date because all of these systems change. 3. **Ask about workflows.** Survey teams with task questions: where do you summarize, draft, transcribe, translate, classify, search, generate images, analyze data, or automate decisions? Follow with short interviews in functions that handle sensitive information. Asking which AI do you use produces a much thinner inventory. 4. **Reconcile and verify.** Match declared tools to domains, accounts, contracts, extensions, and integrations. Confirm the feature, owner, users, inputs, outputs, retention, training terms, permissions, and actions. Mark facts as verified, reported, inferred, or unknown so reviewers do not mistake a guess for evidence. 5. **Decide and revisit.** Approve, constrain, migrate, replace, suspend, or reject each use. Assign an owner, a review date, and a trigger for earlier review. Feed approved options back to employees and watch for the same task appearing through another tool. Use one row per use case, not one row per vendor. The same service may process public marketing copy in one row and customer contracts in another, with different decisions. This compact CSV header is enough to begin and easy to import into a spreadsheet or governance system: ```csv use_case_id,business_task,tool,feature,account_type,owner,user_group,input_data,output_destination,access_scope,automated_actions,retention,model_training,contract_status,evidence_source,evidence_confidence,decision,conditions,review_date ``` A filled record should be specific enough for another reviewer to reproduce the decision. Input data should say customer support transcript with names and order details, not text. Output destination should say private support ticket or public team channel, not internal. Evidence source should point to an admin export, setting capture, contract clause, employee declaration, or observed request. Run a small controlled test when documents disagree. Use synthetic data, observe the network destinations and admin events allowed by company policy, disable the feature, and verify what remains. Do not upload real secrets to discover whether a vendor protects secrets. The test should answer a narrow unknown rather than simulate an entire security assessment. The first inventory will contain duplicates and uncertain names. Keep them until reconciliation proves they are the same use. False precision is worse than an admitted unknown because it lets a reviewer approve the wrong data flow. ## Risk depends on data, reach, and action A simple decision model scores the use case, not the vendor's reputation. Start with four dimensions: sensitivity of input, breadth of access, consequence of output, and ability to act. Add contractual and operational questions after those dimensions identify the review depth. - Input concern stays lower for public or synthetic content and rises for secrets, personal data, contracts, or source code. - Reach stays narrow for one selected item and grows with continuous access to repositories or mailboxes. - Output concern stays lower for a private draft checked by an employee and rises for external messages, production changes, or eligibility decisions. - Action stays limited without write permission and grows when the tool sends, edits, deletes, purchases, or deploys. - Control is stronger in a company tenant with an owner and weaker in a personal account without an administrator. Do not turn the table into a magic numeric score. Two medium-looking conditions can combine into a serious risk, such as a meeting assistant with broad calendar access that posts summaries into a channel with guests. Reviewers need room to describe interactions and set conditions. Numbers help sort a queue, but they do not make the decision. Low-risk approval might allow public content in a company account with no integrations. Conditional approval might prohibit customer identifiers, require human review, limit a connector to one folder, and set a ninety-day review. High-risk uses include secrets in consumer accounts, broad unattended access, external decisions about people, and write actions without recovery or approval. Model quality and information security are separate questions. A service can protect prompts well and still produce unreliable analysis. It can produce excellent text while retaining inputs under unacceptable terms. Assign evaluation for accuracy, bias, and human review to the business owner, while security and privacy specialists examine access, handling, and obligations. One green check cannot stand in for the others. Also price the alternative. Rejecting a tool may leave staff manually copying data into a riskier channel or skipping a required check. The decision record should state the replacement workflow and its owner. Risk acceptance without an operational alternative tends to expire the moment a deadline arrives. ## Ownership keeps the inventory alive A shadow AI inventory stays useful only when ordinary company events update it. New vendor features, employee departures, role changes, OAuth consent, contract renewals, browser extension installs, and changes in data classification should trigger review. A quarterly sweep can catch drift, but event-driven updates keep the gap smaller. Assign business ownership to the person accountable for the workflow, not the security analyst who discovered it. Security can define evidence and review controls. Privacy and legal can interpret obligations. IT can manage identities and configuration. The business owner must confirm the purpose, users, acceptable inputs, expected outputs, and whether the tool still earns its cost and risk. Put expiration into conditional approvals. An experiment may run for thirty days with synthetic or public data, then stop unless the owner supplies evidence for a longer decision. Remove stale OAuth grants and company accounts when the use ends. Preserve the decision record so the next experiment does not restart the argument from memory. Give the inventory its own operating metrics. Track the share of findings with verified owners, the age of unresolved high-risk uses, the time between disclosure and decision, and the number of conditional approvals that pass review before expiry. Compare browser, identity, expense, vendor, and employee evidence to see which collection source keeps finding unique cases. If one source stops contributing, either the company closed that gap or the collection has broken. Test the explanation before removing it. These measures expose whether the program reduces uncertainty and response time. Counting tools alone rewards a small inventory, which a company can achieve simply by looking less carefully. Leadership should review patterns, not a theatrical count of AI tools. Repeated personal subscriptions signal a procurement bottleneck. Many embedded features without owners signal weak vendor management. Broad connectors signal identity design problems. Heavy use for one manual task signals an automation opportunity. The inventory becomes useful when it changes those systems. For a company that wants an outside baseline, the oleg.is Team & AI Audit maps the team and its AI use over five business days, then ties findings to operating savings. The same rule applies internally: demand a named workflow, evidence, an owner, and a decision rather than a slide full of logos. Do not wait for a perfect detection product. Announce the amnesty window, export the evidence you already own, and interview the teams handling the most sensitive work. Within days, the company will know which hidden uses deserve control, which deserve a managed account, and which reveal work that should have been redesigned years ago.