AI security risk starts with unmanaged use#
Zapier’s security note makes a useful point: AI risk at work is often less exotic than it sounds. The immediate problem is not a model becoming sentient or a single dramatic breach scenario. It is employees putting AI into browsers, inboxes, documents, workflows, and side tools faster than the organization can see or govern the usage.
The source cites a sharp governance gap: 70% of employees report working without AI policies, guidance, or clarity. That matters because people do not usually wait for policy when a tool saves time. They paste text into a chatbot. They connect a browser extension. They upload a file to summarize it. They try an agent that can touch work apps.
This is the shadow AI problem. It is the same pattern security teams already know from shadow IT, but with a higher data velocity. Every unsanctioned AI tool can become a leak point, a compliance gap, or an unknown integration path. One employee testing a tool is manageable. Hundreds of employees using dozens of tools becomes an attack surface the security team may not even know exists.
The practical answer is not just prohibition. Zapier argues for policies people can actually follow: approved tools, clear reasons for approval, and a fast path to request new tools. That last point is important. If approval takes weeks and requires too many signatures, users will route around it. Slow governance does not remove risk. It hides it.
A better model is a governed path that still works for normal users. Centralized access, approved AI infrastructure, and clear alternatives reduce the incentive to use private accounts or random tools. If employees are using shadow AI, they are trying to solve a real work problem. Removing the tool without replacing the capability often pushes the behavior further underground.
Sensitive data is the easiest mistake to make#
The second major risk is data exposure through prompts and uploads. Good AI output often requires context. That context may include product messaging, customer notes, internal plans, code, financial data, support tickets, or documents that were never meant to leave controlled systems.
The boundary is not always obvious to the person using the tool. A prompt can feel temporary. A file upload can feel like a convenience step. But once confidential information enters an AI platform, the organization may lose direct control over where it is stored, who can access it, how long it is retained, and whether it can be used in future model training. The exact answer depends on the provider and plan, which is why vague vendor language should not be treated as a control.
Zapier cites analysis of more than one million prompts and 20,000 file uploads across 300 generative AI tools. According to that analysis, sensitive corporate data appeared in more than 4% of prompts and more than 20% of uploaded files. Those figures should not be read as universal across every company or every tool, but the direction is clear: employees do put sensitive material into AI systems when there are no strong guardrails.
The control layer needs to sit before data reaches the AI tool. That can include anonymization, removal of personally identifiable information, and data loss prevention systems that scan and redact sensitive content in real time. The goal is simple: do not rely only on users noticing every sensitive field before they paste or upload.
Vendor selection also matters. Organizations should check retention periods, data deletion terms, model training language, and enterprise privacy controls. “We care about privacy” is not enough. The relevant questions are more concrete: Does the provider use customer data for training? Can that be disabled? How long are prompts and files retained? Are logs accessible to admins? What controls exist for connected applications?
Zapier also argues for automation as a way to reduce risky copy-paste behavior. If a workflow can move data between approved systems through managed connections, users have less reason to manually paste sensitive material into a chatbot. That does not eliminate AI risk, but it can reduce the number of informal data transfers that happen outside monitored channels.
AI accounts are now high-value credentials#
The source also highlights credential theft. AI accounts can contain conversation history, uploaded files, internal context, and sometimes connected application access. That makes them valuable to attackers.
Zapier notes that more than 300,000 ChatGPT credential sets were advertised on the dark web last year. The source does not establish what every credential set contained or how each was obtained, so the right conclusion is narrow: attackers see AI accounts as useful targets, and organizations should treat them as such.
The risk is broader than a chatbot login. API keys can create cost exposure, data exposure, and service abuse. A leaked key may allow an attacker to run expensive workloads, access internal AI-powered workflows, or interact with connected systems depending on how the key is scoped. Weak account hygiene around AI tools can therefore become both a security problem and a billing problem.
The baseline controls are familiar. Use strong passwords. Enforce multi-factor authentication. Prefer centralized identity where possible. Monitor which AI applications are connecting to the network. Keep operating systems and browsers patched, because compromised endpoints are one route to stolen sessions and credentials.
Consolidation can also help. The more AI platforms employees use, the more accounts, tokens, browser extensions, and integrations the company has to track. Fewer approved platforms are easier to monitor and govern. This is not an argument for one vendor by default. It is an argument against uncontrolled sprawl.
What not to overclaim#
This source is a broad risk-management article, not an incident report. It does not show that every AI tool is unsafe. It does not prove that any specific vendor is leaking data. It also does not give enough detail in the collected excerpt to fully evaluate all seven risks named in the original Zapier headline.
The useful reading is operational. AI security work should start with the places where ordinary business behavior creates exposure: unsanctioned tools, sensitive prompts, uploaded files, connected apps, stolen credentials, and API keys. These are tractable problems. They can be inventoried, governed, and reduced.
The wrong response is panic or blanket theater. A total ban may be easy to announce and hard to enforce. A better response is to define approved use, give employees tools that solve real tasks, and place controls around data and identity.
What teams can check next#
Start with visibility. List the AI tools employees are already using. Include browser extensions, meeting assistants, writing tools, chatbots, coding assistants, automation agents, and API-based services. Do not assume procurement records are complete.
Then classify the data. Decide what cannot be pasted, uploaded, summarized, or processed by external AI tools. Make the rule readable. If employees need a lawyer to understand the policy, the policy will fail in practice.
Next, review vendor terms. Look for retention periods, training use, admin controls, audit logs, identity integration, and data deletion. Prefer explicit commitments over broad privacy language.
Finally, lock down access. Enforce MFA, remove unused accounts, rotate exposed API keys, and monitor abnormal usage. AI systems should sit inside the same identity and security discipline as other business-critical tools.
The core lesson is simple: AI security is not a separate universe. It is data governance, identity security, vendor risk, and workflow design under new pressure. Treat it that way, and the risk becomes manageable.