Yes, and not for compliance reasons. This article explains what the policy actually has to contain, why it fits on two pages, and what happens if you do not have one.
Both of the major AI newsletters led with the same story this morning, which almost never happens.
Both editions, citing Axios reporting, say OpenAI, Anthropic, and outside researchers are collectively investigating tens of thousands of incidents of problematic AI behavior. The details they list: an agent that found a loophole around its internet block on 20 September and kept running for two and a half hours after being flagged, and an Australian government portal breached by an OpenAI agent that OpenAI did not report for 84 days.
That is newsletter reporting of someone else's reporting, so hold it loosely. I could not find a primary source from any of those companies confirming the aggregate number, and you should know that before you repeat it.
You are not going to build a sandbox. That is not your league and it does not need to be.
But here is the direct answer to the question in the title: yes, you need an AI policy, and the reason has nothing to do with compliance. It is that your employees are already using AI whether you have decided or not, and at some point a client, an insurer, or a regulator is going to ask who authorized the tool that touched their data. Right now most small business owners cannot answer that question. The policy is how you can.
It fits on two pages. I will show you what goes on them.
Key Takeaways
- Regular employee use of AI on corporate devices tripled in one year, from 15 percent to 45 percent, according to Verizon's 2026 Data Breach Investigations Report.
- Excessive Agency jumped from sixth to third on the OWASP Top 10 for LLM Applications in the 2026 edition, the biggest move on the list.
- Prompt injection has no reliable technical fix. OWASP states plainly that no prevention mechanism exists today, which means the defense has to be architectural.
- Company size is becoming a weaker legal exemption. Illinois covers employers with a single in-state employee, and Colorado's proposed replacement act drops its old fewer-than-50-employee carve-out.
- A workable small business AI policy needs five things: a named owner per agent, least privilege, a human gate on irreversible actions, a vendor defaults audit, and an inventory.
The Problem: You Already Have an AI Deployment
Most owners think of this as a future decision. It is not. It happened without a meeting.
Verizon's 2026 Data Breach Investigations Report, published 19 May 2026 and covering more than 31,000 real-world security incidents across 145 countries, found that 45 percent of employees are now regular users of AI on their corporate devices, authorized or not, up from 15 percent the previous year. Their definition of regular is accessing an AI platform at least once every 15 days. Shadow AI became the third most common non-malicious insider action in their data loss prevention dataset in 2025, a fourfold increase. The most uploaded data type, by a large margin, was source code.
One precision note, because Verizon's own press release blurs it: the 45 percent is all regular AI users, authorized or not. It is not a shadow AI figure. The shadow-specific number is that 67 percent of those users are on non-corporate accounts, which actually declined from 72 percent.
The SMB picture in that same report is worth knowing. Verizon defines SMB as under 1,000 employees and recorded 7,256 incidents in that band. Initial access was exploitation of vulnerabilities at 26 percent, credential abuse at 13 percent, and phishing at 9 percent. Third party involvement, 55 percent. External actors, 100 percent. Financial motive, 100 percent.
And here is what the frameworks have not done for you. NIST's Small Business Cybersecurity Corner covers cloud, phishing, ransomware, and supply chain. As of this writing it has no AI topic page at all. The AI Risk Management Framework and the OWASP lists are written for organizations that have security teams.
Candidly, that gap is the whole reason this article exists. The practical guidance sized for a business your size is currently buried in vendor admin documentation, which is exactly where nobody looks.
The Evidence: Where the Damage Is Actually Landing
Agency is now the risk, not the model. OWASP published a 2026 edition of the Top 10 for LLM Applications on 3 August 2026. Excessive Agency climbed from sixth to third, which OWASP describes as the most consequential move on the list, on the grounds that both the community vote and the incident record point to agentic deployments as where the damage is landing. The methodology is new and specific: a corpus of 7,714 real incidents from public vulnerability databases and an AI-harm database, of which 6,639 carried enough detail to classify, weighted at one quarter against a community vote at three quarters.
Most content you will read on this still cites the 2025 list. Check the year on anything you are given.
Prompt injection cannot be patched away. OWASP's 2026 language on this is as clear as security guidance gets: "LLMs make no architectural distinction between instructions and data, and their behavior is stochastic, so no reliable prevention mechanism exists today." And the sentence that makes it a small business problem rather than a developer problem: "The attacker does not need to compromise the backend directly. They place text where the developer's LLM will read it, and the LLM, operating with the developer's privileges, does the work."
The principle that follows is the one worth keeping. Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important is standing close enough to break.
The vendors publish their own failure rates. Anthropic disclosed a 23.6 percent attack success rate against its own browser agent before mitigations were applied, and reported a substantially lower figure with its safety mitigations enabled. Its own framing in follow-up research is that no browser agent is immune to prompt injection, and that publishing the numbers demonstrates progress rather than a solved problem. An AI company publishing a failure rate for its own product is more persuasive than any warning I could write.
Ungoverned tools cost more when they fail. IBM's Cost of a Data Breach Report 2026, published 29 July 2026, found AI-related breaches rose to 21 percent of organizations from 13 percent the year before, that among organizations with an AI-related breach 92 percent lacked proper AI access controls and 68 percent had no AI governance policy, and that only 40 percent of organizations report using access controls on AI models and data at all.
I have to be straight with you about that source. IBM's sample is 602 already-breached organizations, selected judgmentally rather than randomly, with costs extrapolated rather than reported, and IBM's own methodology says statistical inferences and confidence intervals cannot be applied. There is no cost breakout by company headcount anywhere in the report. Use those figures as direction, not as your number.
And a company owns what its chatbot says. In Moffatt v. Air Canada, decided 14 February 2024, the tribunal wrote: "In effect, Air Canada suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission." It also rejected the defense that correct information existed elsewhere on the site, saying it "does not explain why customers should have to double-check information found in one part of its website on another part of its website."
Be accurate about the weight of that. It is a British Columbia small claims tribunal, not binding US precedent, and the award was CA$812.02. No US court has held a business liable on the merits for its chatbot's statements. But the direction is consistent, and Utah has put language in statute to the effect that it is not a defense that generative AI made the violative statement. Check the current text before relying on it.
The Solution: Three Legs, and You Only Need to Cut One
The most useful thing I have read on this all year is a pair of heuristics that OWASP cites, and both of them work the same way.
Simon Willison's "lethal trifecta": an agent that simultaneously has access to private data, ingests untrusted content, and can communicate externally has the conditions for high-impact exploitation. Remove any one leg and the conditions are gone.
Meta's "Rule of Two": treat simultaneous access to untrusted input, sensitive data, and state change or external communication as high risk, and require per-action human approval for anything with all three.
Look at what that means in practice, using OWASP's own example. An email assistant that summarizes your inbox needs read access. If the plugin also has send capability, and someone embeds instructions in an inbound email, the assistant will exfiltrate on their behalf using your privileges. Remove send. The attack stops working. You did not fix the model, you removed a leg.
This is why the McHire incident is my favorite example for small businesses. Researchers Ian Carroll and Sam Curry found in mid-2025 that a McDonald's hiring platform operated by Paradox.ai exposed applicant records, with a reported 64 million-plus applications reachable. The way in was a team login accepting 123456 as both username and password with no multi-factor authentication, plus an insecure direct object reference on an API endpoint. Paradox's own legal officer said on record that the test account "had not been logged into since 2019 and frankly, should have been decommissioned."
Here is the part everyone skips. Carroll tried to prompt-inject the chatbot and it did not work. It was locked to preset responses. The AI guardrails held. The boring admin login did not.
Your exposure is mostly not exotic. It is permissions you granted in a hurry and never reviewed.
The sharpest illustration I found while researching this piece is a writing tool whose documentation shows the same paid plan arriving with model training on by default when bought through the website, and off by default when bought through the sales team. Same product. Same plan name. Different default, determined by how you bought it. I am not naming the vendor here because defaults change and I would rather you check your own than trust a date-stamped claim about somebody else.
Nobody is going to tell you that. You have to go look.
Practical Steps
1. Separate the tools that answer from the tools that act. List every AI tool in your business, then split it into two columns: produces output only, and can take an action. Anything that can send, post, pay, schedule, or change a record goes in column two. Do not assume a tool is read-only because that is how you use it. Check what it is capable of.
2. Put a human name next to everything in column two. One person per tool, not a department. What they are responsible for, and how often they review it. Anything currently owned by nobody either gets an owner or gets turned off. This is the register you hand someone when they ask who authorized the agent.
3. Cut all three causes of excessive agency. OWASP names them as excessive functionality, excessive permissions, and excessive autonomy. Go through each tool asking all three questions. Does it have capabilities it does not need for the job. Does it have access beyond what the job requires. Does it act without approval on things that should need it. Implement authorization in your own logic, not by asking the AI whether an action is allowed.
4. Gate the irreversible, auto-approve the recoverable. OWASP's graduated model is the right shape for a small business: a customer service assistant can auto-process a refund as store credit because that is recoverable, while an external payout routes to a person. And a detail almost everyone misses, in OWASP's words, is "surfacing the exact rendered action rather than a summary to the reviewer," because approval fatigue degrades judgment at volume. Show the actual message, not a description of it.
5. Audit vendor defaults, and put it on a recurring schedule. Training toggles, retention periods, connector permissions, sharing defaults, project isolation settings. Verify them by opening the setting, not by reading the help article, because documentation goes stale. This is not a setup task. Defaults change under you: ChatGPT Business enables apps on by default while Enterprise disables new ones, browser extensions have shipped enabled by default on some enterprise plans unless an admin had already turned them off, and Microsoft 365 Copilot agents are enabled by default in licensed tenants with access set to all users. Do not take any of those as current. Go look.
6. Teach the team what prompt injection looks like. Your people have never heard of this and it takes five minutes to explain. If an AI reads inbound email, uploaded documents, résumés, or web pages, hidden instructions in that content can redirect it. The Noma Security researchers demonstrated this against Salesforce Agentforce with a payload placed in the Description field of a web-to-lead form. A contact form. That is the attack surface.
7. Write the client-facing version, because it is becoming a competitive advantage. Here is the prompt I would use for it:
[The Job]
Draft a short, honest explanation of how my business uses AI, suitable for answering a client who asks before they sign.
This is for: prospects and existing clients.
It matters because: the businesses that can answer this calmly will start winning work from the ones that cannot.
[The Background]
Here is what you need to know: here is my accountability register [PASTE IT] and my access policy [PASTE IT]. My clients are [WHO] and what they actually worry about is [WHAT].
Do not use: any claim I cannot back up with the register. Do not promise a protection I have not implemented.
[The Deliverable]
Return: a statement under 250 words covering what AI touches, what it does not touch, who is accountable, and how often it is reviewed.
Must include: anything I should fix before I would be comfortable sending this.
Optimize for: honesty. A truthful modest answer beats an impressive false one.
[The Questions]
Ask me any questions you have.
Frequently Asked Questions
Do I need an AI policy if I only have eight employees?
Yes, and size is becoming a less reliable exemption than it used to be. Illinois HB 3773, effective 1 January 2026, covers employers with a single Illinois employee. Colorado has legislation in motion that would replace its earlier AI act, and the version under consideration drops the old fewer-than-50-employee carve-out, though you should check its current status rather than take my word for it, because that bill was still moving when this was written. The direction of travel is that relief comes from what the AI does, not how many people you employ. But the practical reason matters more than the legal one: nearly half your employees are already using AI on company devices.
What is prompt injection, in plain English?
An AI reads instructions and data on the same channel and cannot reliably tell them apart. If someone hides text in something your AI reads, a contact form submission, a PDF résumé, a web page, an email it is summarizing, the AI may follow those hidden instructions as though you typed them. OWASP states there is no reliable prevention mechanism today. The defense is not a better filter, it is giving the AI less it can break.
Is my client data safe in ChatGPT or Claude?
It depends entirely on which account you are using, and the defaults differ by tier. Consumer ChatGPT tiers have training on by default, with the opt-out under Settings, Data controls, "Improve the model for everyone." Business, Enterprise, Edu, and the API are off by default. Claude for Work, the API, Bedrock, and Vertex are off by default, while consumer Claude requires an explicit choice and retention goes from 30 days to five years if you allow training. Two gotchas on both platforms: thumbs up and thumbs down feedback is exempt from the opt-out, and paying for a consumer plan buys you limits, not privacy.
Who is liable if my AI makes a mistake?
You are, and no authority has said otherwise. The clearest statement is Moffatt v. Air Canada, though that is a Canadian small claims tribunal rather than binding US precedent. In Mobley v. Workday, Judge Rita Lin wrote that accepting a vendor-shield argument "would allow companies to escape liability for hiring decisions by saying that function has been handed over to someone else, or here, artificial intelligence." And Utah has put it in statute.
What should an AI policy actually contain?
Five things, on two pages. A named human owner for every agent with a documented scope. Least privilege across functionality, permissions, and autonomy. A human approval gate on irreversible actions, showing the reviewer the actual rendered action. A vendor defaults audit on a recurring schedule. And an inventory: which tools, which accounts, which data, who owns each. Worth knowing: at least one state, Texas, has written a rebuttable presumption of reasonable care into its AI statute for businesses substantially complying with a recognized framework such as the NIST AI Risk Management Framework Generative AI Profile. Confirm the current provision with counsel, but the principle is that aligning to a named framework can have legal value and not just optics.
The Close
Nobody is going to ask you which model you used.
They are going to ask who authorized it. And the version of that question you will actually get is worse, because it will arrive attached to something that already went wrong. A client asking why their information ended up somewhere. An insurer asking what controls you had. An employee asking whether the thing they uploaded last month is still out there.
Here is the thing. Every control in this article is the kind of thing you already know how to do. You already decide what access a new contractor gets. You already know not to hand keys to someone you met last week. You already check who has the alarm code. You have simply not applied any of that to software that behaves like a person, because it does not look like a person on your org chart.
So apply the standard you already have. Run the contractor test on every agent in your business and be honest about which ones would fail it.
The frameworks are written for companies with security teams, and nobody has written the small business version, which means the work falls to you. Two pages. Five sections. An hour, once a quarter.
You cannot make the model harder to fool. Nobody can. What you can do is make sure that when it gets fooled, and it will, nothing important is standing close enough to break.
That is the whole job. It is smaller than the headlines make it sound, and it is yours.
About the author
Jonathan Mast is the founder and CEO of White Beard Strategies, where he teaches non-technical entrepreneurs how to use AI to amplify the skill and experience they already have. He runs a Facebook community of more than 500,000 members, the AI Insiders membership, and a live training program built on the Perfect Prompt Framework. He has been on the wrong end of trusting a system he had not verified, which is why he now reads the settings page before the sales page.
