Shadow AI at a Startup That Can't Buy a CASB

TL;DR: Every “shadow AI” article on page one is written by a vendor selling you a CASB — a piece of enterprise software that watches every cloud app your employees touch and enforces a policy about what data can go where. It’s the right tool at 500 employees and the wrong conversation at 12. You don’t need software; you need three free things done in the next two weeks: a card-statement-and-SSO-log audit to see what’s actually connected, a no-blame survey to find what isn’t, and a one-page policy with a plain data-classification rule. The part that determines whether any of it works isn’t the audit — it’s whether the survey is genuinely no-blame. Punish the disclosure once and the tools don’t go away, they just go invisible, and invisible is the actual risk, not usage.

What “shadow AI” actually means, and why the standard fix doesn’t fit you

Shadow AI is a specific, boring thing: your employees are pasting company information into AI tools you never approved, evaluated, or even know exist. Someone drops a customer’s support ticket into ChatGPT to draft a better reply. Someone uploads a contract to Claude to summarize it. Someone connects a Notion doc to a Chrome extension that “makes your writing better” and never reads what permissions it asked for. None of it is malicious. All of it is your company’s data now sitting on infrastructure you didn’t choose, under a data-handling policy you never read, and — depending on the tool’s terms — sometimes feeding a model you have no relationship with.

The scale of this is not a niche worry. Verizon’s 2026 Data Breach Investigations Report found that the share of workers using AI tools on corporate devices tripled in twelve months, from 15% to 45%, and that shadow AI is now the third most common non-malicious insider action showing up in data-loss-prevention logs — a fourfold year-over-year increase (Verizon, 2026 DBIR). A separate 2026 survey of 1,250 office professionals at large organizations found two-thirds had used an AI tool at work despite believing it wasn’t permitted under company policy, and 88% had shared work-related information with a public AI system — 34% customer information, 31% sensitive business documents (PagerDuty, 2026 Shadow AI Workplace Survey). Those numbers are from companies with a compliance department. At a 12-person startup, nobody’s even counting.

Every piece of enterprise coverage on this topic converges on the same fix: buy a CASB. A cloud access security broker is software that sits between your employees and every cloud app they touch, discovers what’s connected (often via OAuth grants and network traffic), and enforces a policy — block this category, allow that one read-only, flag anything touching a data type you’ve labeled sensitive. Palo Alto, Netskope, Zscaler, and a wave of AI-specific entrants now sell exactly this for the “shadow AI” problem specifically. It’s a real product solving a real problem, and it is comically oversized for a 5-15 person company. A CASB assumes a procurement process, a security team to tune its rules, a device fleet uniform enough to enforce an agent on, and a budget line that starts in five figures a year before you’ve hired anyone to run it. You have none of that, and you’re not supposed to yet — buying one now is the same mistake as buying a full-time CISO before you have a security program for them to run, and I’ve written about why that hire ordering is backwards at your stage.

So skip the vendor conversation entirely. Here’s the version that costs nothing and takes about two weeks of part-time attention, which is the version I actually run with clients at this stage.

Step 1: the audit you already have the data for

Before you ask anyone anything, find out what’s already connected. You don’t need a discovery tool — you need two things you already pay for.

Your corporate card statement. Pull the last three months from Brex, Ramp, or whatever you use, and search for AI vendor names: OpenAI, Anthropic, Perplexity, Otter.ai, Jasper, Gamma, Grammarly, Fireflies, Clay, and the dozen coding and writing assistants that bill monthly. Every one of these is an employee who decided the company needed a tool badly enough to expense it, and every one of them is a data flow you didn’t design.

Your SSO or Google Workspace admin console. If you’re on Okta, Google Workspace, or Microsoft Entra, there’s an admin view of every third-party app your employees granted access to via “Sign in with Google” or “Sign in with Microsoft” — usually under something like connected apps, OAuth grants, or the security/API access report. This surfaces the free tools that never touch a card: the ChatGPT account someone connected to their calendar, the note-taking AI that reads their email, the browser extension with access to every page they visit. This report already exists in tools you’re paying for regardless; you’re just looking at a screen you’ve never opened.

Between the two, you’ll have a real list in under an hour — not a complete one, but a real one. That’s the baseline. Everything from here is closing the gap between what this audit found and what’s actually happening.

Step 2: the no-blame survey, and why the “no-blame” part is the whole mechanism

The card-and-SSO audit misses the AI use that never touches company infrastructure at all: the free ChatGPT account logged in with a personal Gmail on a personal laptop, opened in an incognito tab specifically because someone suspected it wasn’t sanctioned. You cannot audit your way to that list. You have to ask for it, and the only way anyone tells you the truth is if the asking is genuinely, verifiably safe.

Send one short form, from a founder, with a plain ask: “What AI tools do you actually use for work, day to day, for what? No one is in trouble for anything on this list — we’re trying to understand our real exposure, not build a case against anyone.” Anonymous or not doesn’t matter much at 12 people; what matters is that the promise is real and someone tests it by naming something borderline.

This isn’t a soft HR nicety bolted onto a security process — it’s the same mechanism that governs whether anyone reports a phishing click, and I’ve written about that mechanism in more depth: a scared team is your biggest attack surface. Punish the first honest answer to a survey like this — even mildly, even just a raised eyebrow in Slack — and you haven’t reduced the AI usage. You’ve taught your team to keep doing exactly what they were doing, quieter. The tool doesn’t leave; your visibility into it does. Given the choice between a team that uses an unapproved tool and tells you, and a team that uses the same tool and hides it, the second is strictly worse — you’ve traded a known, manageable risk for an invisible one, for free, by reacting badly once.

Step 3: one page, one rule, no procurement

You don’t need a policy document. You need a data-classification rule simple enough that someone can hold it in their head mid-task, because that’s the only place a policy actually works — nobody re-reads the wiki before pasting a ticket into an AI tool. A workable version fits on one page and looks roughly like this:

The specific tools you name in the “approved” column matter less than the fact that a rule exists at all and someone can check it in ten seconds. Most AI vendors now offer a business tier with a data-processing agreement that contractually excludes your data from training — that’s the tier worth naming as approved for internal-but-sensitive work, and the free consumer tier is the one worth explicitly ruling out for anything past “public.” Write it, put it somewhere every new hire actually sees in week one, and revisit it once a quarter as the tools your team actually uses shift — which the survey in step 2 will keep telling you, if you run it again in six months.

None of this requires a vendor call, a trial, or a line item. It requires a founder spending a focused afternoon on an audit, a form, and a table — which is precisely the kind of decision-not-implementation work that fractional security leadership exists to run for you when you don’t have the bandwidth yourself, and it’s the same category of hours-per-month math I’ve laid out for vCISO cost versus a full-time hire.

When you actually outgrow this

The free version has a real ceiling, and pretending otherwise past that point is its own risk. You’ve outgrown it when any of these become true:

You’re handling regulated data. Health records, payment data, anything that triggers HIPAA, PCI, or a state privacy law changes the calculus entirely — the free playbook is a starting posture, not a compliance program, and regulated data needs contractual and technical controls a one-page table can’t provide. If that’s you from day one, most of this article still applies as your baseline, but you need it paired with the fuller security architecture I’ve described in how I’d run security at an AI-native company in 2026.

An enterprise customer’s security review asks the question directly. Once a prospect’s procurement team is asking “how do you govern employee use of AI tools,” a verbal answer and a Google Doc stop being sufficient evidence, even if the underlying practice is sound — you need something closer to a documented, monitored program, and that’s usually the actual trigger, not headcount.

Your identity provider already has the feature for free. If you’re already on Okta or Google Workspace at a tier with an app-discovery or OAuth-grant report, you’re most of the way to CASB-lite functionality with zero new spend — check what your existing IdP surfaces before buying anything new that duplicates it.

You’ve crossed roughly 25-30 people with no security owner. Past that headcount, the no-blame survey and the one-page policy stop scaling on founder attention alone, and you need someone accountable for re-running the audit, updating the policy, and fielding the “can I use this new tool” questions that start arriving faster than a quarterly check-in can absorb. That’s usually the same inflection point where the vCISO-first hiring order I’ve written about elsewhere starts to apply.

Until one of those is true, the CASB conversation is a distraction dressed up as diligence. The actual failure mode at your stage was never “employees use AI.” It’s finding out which tool, with what data, from a customer’s security questionnaire instead of from your own team — and the fix for that costs an afternoon, not a contract.

If you want a second pair of eyes on where your actual exposure sits — or you’re staring down the first enterprise security review that’s going to ask this question in writing — that’s the conversation I have with founders every week.