Your Biggest AI Risk Isn't ChatGPT — It's "Sign in with Google."
If you're fast-growing and cloud-native your shadow-AI problem doesn't look like an employee pasting data into a chatbot. It looks like the OAuth grant nobody audited. Here's how to get visibility across identity, your devices, and the network — without slowing the team down.
When "shadow AI" lands on a startup's radar, the instinct is to worry about ChatGPT. But the chatbot is the least of it. The risk that actually bites is quieter: the AI tools your team connected to your tenant with a single click — and the agents they wired up to run on their own.
"Shadow AI" has become the catch-all term, and it hides a split that matters. The first kind is usage: someone opens a browser AI tool and pastes in a customer list. The second kind is creation and connection: someone builds something that runs on its own, or hands an outside AI tool the keys to your data — a Google Apps Script firing on a trigger, a Zapier or n8n flow wired into your stack, a script on a laptop calling an LLM API, or an AI note-taker granted access to every calendar and inbox in the company.
The first is a data-handling problem you can mostly catch in the browser. The second is an autonomy-and-access problem that lives in your identity layer, your SaaS apps, and your laptops — places a startup rarely thinks to look. Treat them as the same problem and you'll lock down ChatGPT while the real exposure keeps compounding in your admin console.
For a cloud-native startup, the dangerous AI isn't the one your people type into. It's the one they granted access to and forgot about.
Two problems wearing one name
The easy one first. When someone uploads a spreadsheet to a browser AI tool, that traffic leaves the laptop. In principle it's catchable. It's the shadow AI every vendor is selling against, and it's real — but it's tractable, and your team mostly knows they're doing it.
The hard one is the stuff that doesn't look like a person using AI at all. A developer connects an automation platform to your CRM and points it at a model, and now an agent drafts and sends emails on its own. An analyst wires a no-code automation to pull from a database and post a summary somewhere on a schedule. Someone authorizes a slick new AI scheduling tool with "Sign in with Google," and it quietly holds read access to every email and file that account can touch — indefinitely, even after they stop using it, even after they leave. None of that crosses your awareness as "AI usage." It just runs.
This isn't theoretical. Gartner projects that by the end of 2026, roughly 40% of enterprise applications will include task-specific AI agents — up from under 5% a year earlier. And in one recent industry survey, 82% of organizations said they'd found at least one AI agent or workflow that IT and security didn't know existed. Startups are the most exposed, because the culture is to move first and ask later.
Where a network tool fits (and why it's not your first move)
You'll hear that the answer is a network platform — a SASE or CASB that watches traffic and flags AI. There's real substance to that. Cato Networks is a strong example of how capable that layer has become. Its CASB ships a shadow-AI dashboard backed by a catalog of 950-plus GenAI applications, so it can separate sanctioned tools from unsanctioned ones and risk-score each. It gives user-level visibility into who is using AI and through which channel — browser, API, or embedded-in-another-app — and its AI-aware DLP uses machine-learning classifiers to inspect what's actually being shared, so you can catch source code or a customer list heading into a model rather than just noting that "someone visited an AI site." The policy engine then works at the action level: allow, monitor, or block specific behaviors like uploads, downloads, logins, or prompts, per user or group.
The piece that makes any of this actually work is SSL decryption. Nearly all AI traffic is encrypted HTTPS, so unless the platform is decrypting and inspecting it, the DLP and app-visibility are mostly blind — they see the destination, not the prompt or the file going into it. Done properly — the inspection certificate pushed to managed devices, a sane decryption policy, and the platform's agent forwarding traffic from the endpoint itself — TLS inspection lets the AI controls see inside the session, and it lets you enforce the same policies whether a laptop is on the office network or on a café hotspot. That on-and-off-network parity is the whole point of the model. Skip the decryption piece, or deploy it halfway, and you're left with a dashboard that mostly shows you nothing.
Cato isn't alone at this tier. It has invested heavily in AI visibility and security, but several SASE/SSE platforms offer comparable capabilities, and the right one usually comes down to what you already run rather than a feature checkbox. Zscaler brings proxy-scale inspection and AI-usage analytics through its Zero Trust Exchange. Palo Alto Networks layers AI Access Security (visibility and control across 800-plus GenAI apps) and Prisma AIRS (runtime protection) onto Prisma Access. Cisco (Secure Access) and Cloudflare (Cloudflare One, with an AI Gateway) round out the field, the latter newer and lighter on deep DLP. They all inspect the same encrypted AI traffic the same way — the depth of their classifier libraries and per-app coverage is where they diverge.
If you already route traffic through one of these, turning the AI controls on is mostly configuration. But notice the assumption baked in: that your traffic flows through a network platform in the first place. Most fast-growing, remote-first startups don't have a datacenter, don't backhaul traffic, and haven't deployed SASE yet. Their people work from home and coffee shops, signing into cloud apps directly. In that world, the network layer is one useful option for catching browser-based AI usage — worth doing, but not where the real risk is hiding today.
That's a property of where it sits, not a flaw — and it's true of every platform in the category, Cato included. It's strong on managed devices and the browser. It's blind to a server-to-server API call between two cloud services, and to an OAuth token an outside AI app uses to read your Google Drive. For a cloud-native startup, that second category is exactly where the exposure lives.
Where your risk actually shows up
Getting real visibility means watching the places agents and AI tools actually live in your stack — and the good news is you already own most of them. No single product covers everything, so the practical question is "which layers do I have, and where's the gap."
| Best at seeing | Blind spot | |
|---|---|---|
| Identity & app grants Okta · Workspace / M365 admin | Which AI tools were granted access to mail, files, and calendars — the OAuth scopes, tokens, and service accounts agents authenticate with | What a tool does on its own servers once it holds the token |
| Endpoint Kandji · Jamf · Fleet · Intune | Local scripts, CLI agents, and AI apps a developer spun up on a laptop | Cloud-side automations that never touch the device |
| Network / SASE Cato, et al. — one option | Browser AI usage and data leaving managed devices | Token-based access and server-to-server calls that skip the network |
| AI governance WitnessAI · Lasso · Zenity, et al. | Discovery, ownership, and audit across all of the above; framework mapping | Adds cost and another console to run |
Start with the top row, because it's the one almost nobody opens and it's where the real exposure lives. Identity is the most under-used angle in this whole conversation. A huge share of agent risk isn't a person at all — it's the tokens and service accounts that AI tools and automations authenticate with. See and govern those, and you catch a mountain of activity that never crosses your network and never registers as someone "using AI."
The concrete move is to open the console you already pay for. In Google Workspace, that's Security → Access and data control → API controls → App access control, where you can see every third-party app connected to your domain, the exact OAuth scopes each one asked for, how many people authorized it, and flip each to Trusted, Limited, or Blocked — then export the lot to a CSV. If part of your stack runs on Microsoft 365, the equivalent review lives in Microsoft Entra under enterprise applications. Either way, the first time a founder runs this it's a surprise: dozens of apps holding live access to company mail and files that no one remembers approving.
If your sign-ins run through Okta — as they do at most startups that have outgrown raw Google auth — that's the other half of the picture, and it deserves equal attention. Okta is where you see and control which applications your people can connect to in the first place, and where you decide whether adding a new one needs admin approval. It's also where offboarding either works or doesn't: a standing OAuth token is the classic thing that outlives an employee, and disabling someone's login doesn't automatically revoke the apps they authorized. Okta's lifecycle management is what makes deprovisioning actually sever that access, and Okta Identity Governance layers on periodic access reviews so dormant, over-scoped grants get caught instead of quietly piling up. Treat the Okta admin console as a peer to your tenant admin — not an afterthought to it.
The fix is just as concrete: enable an admin consent workflow — Google Workspace and Microsoft 365 both have one — so employees can no longer hand an outside app access to the tenant on their own. It turns a silent, self-service grant into a one-line approval request, which is exactly the speed bump a fast-moving team can live with.
In April 2026, Vercel confirmed a breach that didn't begin with a zero-day or a phishing email. It traced back to a small third-party AI tool that had been granted access to Vercel's Google Workspace — and whose OAuth app was later compromised, exposing data across hundreds of organizations that had connected it. An employee was able to grant an unvetted vendor standing access to a production tenant, and nothing flagged it. The same one-click grant is available in a Microsoft 365 tenant, too. It's a governance gap, not a technical one — and it's sitting in most startups' admin consoles right now, unreviewed.
The endpoint layer is where you catch the agents that never leave the laptop. A developer spins up a local script on a trigger, or runs a CLI agent that calls a model and touches the file system — none of it visible to a network tool or an admin console. Device management is how you see it. A turnkey MDM like Kandji or Jamf (or Intune, if part of the fleet runs Windows) gives you an inventory of what's installed and configured on each machine. For an engineering-heavy team, an osquery-based platform like Fleet goes further: because it can query what's actually running on a device in near real time — processes, not just installed apps — it's well suited to catching the local script or CLI agent a developer stood up. The trade-off is that Fleet leans developer-operated and GitOps-driven rather than point-and-click, which fits some startups perfectly and overwhelms others.
The same "granted with a click" problem shows up in your other SaaS, too. The clearest example is your chat tool: requiring app approval in Slack so members can't install integrations on their own is the direct analog of the tenant consent workflow — another self-service grant turned into a deliberate one.
When the agent gets hijacked
There's a second risk with DIY agents that has nothing to do with who built them and everything to do with what they read. The moment an agent acts on your behalf — summarizing your inbox, browsing a page, digesting a shared doc — it's processing content an attacker may have written. And to a language model, there's no clean line between "content to read" and "instructions to follow": both arrive as the same stream of tokens. Hide a command inside an email, a web page, a calendar invite, or white text in a PDF, and the model's instinct is to comply. This is prompt injection, and against an agent it isn't a prank — it's a way to make your own tools work for someone else.
Security researcher Simon Willison's shorthand for when this turns dangerous: an agent becomes exploitable the moment it combines three things — access to private data, exposure to untrusted content, and a way to communicate outward. An assistant that reads your email (private data plus untrusted content) and can also send email (outward) has all three. A single hidden instruction in one received message can quietly make it forward sensitive data to an attacker, using your own permissions. It's a classic confused-deputy attack in a new coat of paint.
This isn't hypothetical, and it isn't a sign someone built the agent badly. In early 2026, researchers demonstrated working injection exploits against a string of mainstream, professionally built AI productivity tools inside a single week, and Google's threat-intelligence team flagged a measurable rise in injection payloads seeded across the open web. OWASP's 2026 guidance is blunt about why: the flaw is architectural. A model has no built-in way to tell a trusted command from untrusted data, so instructing an agent to "ignore any instructions you find in content" is not a reliable defense — attackers can write around it. Treat hijacking as likely, not as an edge case.
You don't fix prompt injection with a cleverer prompt. You fix it by changing what the agent is allowed to do.
Because the weakness is structural, the defenses are too — and most of them are decisions about architecture and permissions rather than a product you buy:
- Break the trifecta. The single most effective move is making sure no agent holds all three powers at once. An agent that reads untrusted content shouldn't also be able to send mail, post externally, or call arbitrary URLs. Separate the thing that reads from the thing that acts, and the exfiltration path disappears.
- Scope it down. Treat an agent like a privileged service account, because that's what it is. The narrow OAuth scopes from the identity section do double duty here: an agent that can only read one calendar can't leak your whole Drive, no matter what it's tricked into doing.
- Put a human on consequential actions. Sending, deleting, sharing, paying — anything irreversible — should require a person to approve it, not run autonomously on the agent's say-so.
- Constrain where it can send data. Allowlist the destinations an agent can reach. Most exfiltration rides out on an outbound request — a rendered image, a generated link, an API call — that a tight egress policy would have blocked.
- Detect at the network and governance layers. This is where the earlier layers earn their keep. SASE/SSE platforms like Cato (and Palo Alto's Prisma AIRS, among others) include engines that flag jailbreaks and prompt-injection attempts, and the purpose-built governance tools watch agent behavior for the moment it deviates from baseline. Useful — but a backstop. A classifier in front of a trifecta-violating agent buys you time, not safety.
- Keep a real audit trail. Tamper-evident logs of what each agent did, under which identity, are how you investigate when something does slip through — and increasingly what an auditor will ask to see.
How to actually get visibility
Strip away the product names and it's three moves, in order. You can't govern what you can't attribute, and you can't attribute what you can't find.
Open the admin console and list every connected app and agent, tie each to an owner and a scope, then decide what's allowed and turn on consent control. For a startup, this is an afternoon — not a procurement cycle.
The order matters for a startup specifically. The temptation when "shadow AI" hits the leadership channel is to go buy the tool with "AI" in the name. But your highest-leverage hour isn't a purchase — it's the OAuth audit in a console you already pay for. Discovery and attribution for the large majority of real-world agents already live across your identity provider, your tenant's admin console, and your device management. A dedicated AI or SaaS-security platform — the purpose-built governance layer — earns its place after that: once you're handling compliance pressure, or once the number of self-built agents outgrows what your existing tools can attribute and audit.
When that day comes, the purpose-built field sorts roughly into three jobs. For shadow-AI discovery and GenAI data-loss controls, look at names like WitnessAI, Lasso Security, and Harmonic Security. For governing the autonomous agents themselves — attribution, identity-linked audit trails, MCP tool calls — Zenity and Aurascape sit closer to the action. And for mapping all of it to frameworks like the EU AI Act or NIST, governance platforms such as Credo AI do that work. One caveat worth pricing in: this category is consolidating fast — Prompt Security was absorbed into SentinelOne, Lakera into Check Point, Protect AI into Palo Alto — so several "standalone" tools now ship inside a larger platform. Confirm what's actually a product you can buy on its own before you build a shortlist around it.
AI-agent security and governance features are shipping faster than documentation can keep up — across the identity providers, device-management vendors, network platforms, and dedicated governance tools. Capabilities described here were accurate at publication but move quickly. Confirm current behavior against the vendor before you make a buying decision on a single feature.
Frequently asked questions
The buyer's-agent take
Startups don't have a shadow-AI problem because their people are careless. They have one because the path of least resistance — "connect this helpful AI tool to my work account" — is one click, and nothing in the environment slows it down. That's fixable, and it mostly doesn't cost anything: it's an audit and a setting, not a purchase.
We don't sell any of these platforms, and we're not paid more to steer you toward one. That's the point of a buyer's agent. We help you open the consoles you already own, map the AI tools and agents actually running, and turn on the lightweight controls that protect the business without grinding the team to a halt — and we only put a new tool on the table when there's a real gap it closes. The goal isn't more software. It's knowing what's connected.
Want to know what's already connected to your tenant?
We'll run the OAuth and agent audit across your Google Workspace, identity, and devices — and tell you straight where the real gaps are. No pitch, no platform.