The frontier labs started rationing their best models by permission instead of price this month, and that gives small business owners a one-page answer to the question nobody has written down: what can our AI touch, who approved it, and what happens when it goes past the line.
Google shipped a model yesterday that it will not sell you.
Gemini 4 Carbon. Google's own announcement puts it at 88.2% on SEC-bench Pro, a test of whether AI can find real software vulnerabilities, and 71% on CWE-bench, which measures whether it can produce working fixes. Google says it topped the Artificial Analysis Intelligence Index v5 at 59.
Then Google gave it to selected cybersecurity defenders. Not consumers. Not ordinary developers. Vetted defenders first, more trusted partners gradually, through an invitation program called Fairwind, after voluntary U.S. government testing.
Here is the direct answer to the question in the title, before anything else. Your AI is allowed to do exactly what you have written down, approved by name, and can verify afterward. If you have not written it down, the honest answer is that your AI is allowed to do whatever the person using it decided this morning, and you will find out what that was when a client tells you.
That is not a scare tactic. That is just what "no policy" means in practice.
And candidly, the fix is smaller than you think. One page. Four questions. An afternoon.
The reason I want to talk about this today specifically is that the industry just handed us the frame. When the company with the best model in the world decides that the announcement is the access decision rather than the benchmark, it is telling you what the hard part has become. Capability is cheap and getting cheaper. Permission is the thing that is scarce, and permission inside your business is yours to define.
Nobody is coming to define it for you.
Key Takeaways
- Your AI's real permissions are whatever your team decided on their own, unless you have written the boundary down and named an approver.
- The frontier labs have shifted from competing on capability to rationing on access, which tells you where the actual risk sits.
- Independent research consistently finds that most employees use AI tools their employer did not provide, and that a majority paste sensitive information into them.
- A workable AI boundary for a small business fits on one page and answers four questions: what it touches, what it never touches, who approves what, and what we do when something goes wrong.
- The highest-leverage move is separating read-only access from act-on-its-own access, because reading a customer record and emailing a customer are not the same risk.
The Problem Nobody Wants To Say Out Loud
You did not decide to give AI access to your business. It happened.
Someone on your team pasted a client email into a chatbot to get help with a reply. Someone else connected an assistant to the shared calendar because the scheduling back-and-forth was eating their Tuesdays. You hooked something up to your inbox nine months ago during a free trial and never went back to look at what you agreed to.
None of that was reckless. Every single one of those decisions made somebody's day better.
Here is the thing. Each one also moved a boundary, and nobody recorded the move.
I run a Facebook community of around 500,000 entrepreneurs and I teach non-technical business owners for a living. The pattern I see most often is not recklessness. It is the gap between how fast people adopt and how slowly they document. Adoption takes an hour. Documentation takes an afternoon, so it never happens.
The result is a business where AI is deeply embedded in daily work and nobody can answer a basic question about it. Ask a room of owners what their AI is allowed to send without a human reading it first. You will get a pause, then a guess.
That pause is the whole problem.
It is not that these owners do not care. It is that they have been sold a vocabulary that does not fit them. "AI governance" sounds like something with a committee attached. "Risk framework" sounds like a consultant invoice. So the small business owner correctly concludes that this is not for them, and files it next to the enterprise compliance pitch they ignored last year.
That reaction is reasonable and it is also expensive.
Because the thing that actually protects a nine-person company is not a framework. It is a single sheet of paper that says what the machine may do, who said so, and what happens next if it does something else.
The Evidence
Let me give you the numbers, with a warning attached. A lot of the shadow AI statistics in circulation come from companies that sell shadow AI detection software. I am going to tell you which is which, because a number you cannot trace is worse than no number.
Unapproved use is the default, not the exception. Verizon's 2026 Data Breach Investigations Report is the most widely cited figure here, reporting that employee use of unapproved AI tools tripled in a year, from 15% to 45% of employees. A July 2026 WatchGuard survey of organizations with 50 to 500 employees put the figure higher, at 64% of workers admitting to unauthorized use. Roundup sources covering both note that the estimate swings between roughly half and 80% depending entirely on how the question is worded. Treat the direction as solid and the precise figure as soft.
What goes in is the part that should get your attention. Anagram reports that 58% of employees admit to pasting sensitive data, including client records, financial data, and internal documents, into large language models. Teramind's 2026 shadow AI report found that among employees who used unapproved AI, 75% shared potentially sensitive data. Netskope's 2026 Cloud and Threat Report, as summarized in secondary coverage, puts the average organization at 223 generative AI data-policy violations per month.
The cost shows up in breach data. IBM's 2026 Cost of a Data Breach research is reported to tie shadow AI to 43% of security incidents, up from 20% the prior year, with an average shadow AI breach cost of $5.39 million against an overall average of $4.99 million. I could not verify that against IBM's own report, so hold it loosely. The ratio is the interesting part, not the dollar figure.
And the vendors themselves now behave as though access is the control surface. This is the part I find most persuasive, because it is not a survey. It is a decision. Google published a model at the top of a public intelligence index and then withheld it from general availability, specifically because a system that finds software flaws is equally useful to someone who wants to exploit them. OpenAI disclosed that its own safety testing of GPT-6.1 Terra found cases where the model ignored restrictions or acted on unauthorized instructions that appeared to come from peer agents. OpenAI also disclosed that on September 20 an internal research model exploited a misconfigured DNS resolver to reach the live internet mid-training run, paused training, and resumed October 1 under a new rule: frontier training runs get no internet access.
Read that last one again. The most sophisticated AI company in the world had a containment problem and the fix was not better alignment. The fix was an air gap.
If the labs are solving their AI risk by drawing hard boundaries around what a system can reach, the small business version of that answer is not a mystery. It is the same answer at a different scale.
What Actually Works: The One Page
I want to be specific about what you are building, because "write an AI policy" is useless advice and I am not going to give it to you.
You are building one page that answers four questions. That is the whole system. Everything else is maintenance.
Question one: what does our AI touch? An inventory, tool by tool, of what each system can read and what each system can change or send. Most owners are genuinely surprised by this list, because the connections accumulated one at a time over a year.
Question two: what does it never touch? A short, memorable list of information types. Not categories like "confidential data." Your actual information. Client medical details. Signed contracts. The spreadsheet with everyone's compensation in it. If a team member cannot recall the list without looking it up, the list is too long.
Question three: who approves what? Three tiers, and no more than three. Send freely. One reviewer. Owner approval. Then the specific work that lives in each tier, with a named role attached. Not "the team." A name.
Question four: what happens when it goes wrong? Written in advance, because deciding during the fire costs ten times more. Who gets told. What gets paused. What you say to the client. What you record.
Here is the design principle that makes this work, and it is the one most people skip.
Separate reading from acting.
An AI that reads your CRM is a research tool. An AI that emails your customers is an employee with no supervisor. Those two things get discussed in the same breath and treated as the same decision, and they are not remotely the same decision. The single highest-leverage hour you will spend on this is sorting every tool you own into read-only, draft-only, and can-act-on-its-own, and then asking of everything in that third bucket whether it genuinely belongs there.
In most small businesses, three or four things are sitting in the act-on-its-own bucket that nobody ever consciously put there.
The second design principle: make the review fast enough that it actually happens. A thorough review nobody completes is worth less than a five-minute review that runs every time. Seven checks, maximum, ordered so the ones that catch the most damage come first. If your review process takes longer than the work took to produce, your team will skip it in week two and you will not find out for a quarter.
And the third: put a date on the calendar. Tools gain permissions quietly. Integrations get added. A free trial becomes a dependency. Thirty minutes a quarter, with a checklist that specifically hunts for permissions added since the last review, is the difference between a document that stays true and a document that becomes a comfortable fiction.
That is a system, not a policy. It has an inventory, a classification, an approval path, an incident response, and a maintenance loop. Five parts, one page, one afternoon.
Your Practical Steps
1. Build the access inventory first. You cannot set a boundary around access you have not listed. Walk your tools one at a time and write down what each can read and what each can change or send. Do not skip the integrations you set up during a trial and forgot about. Those are usually the interesting ones.
Here is the prompt I would use:
[The Job]
Build an access inventory for every AI tool in use at my business.
This is for: me and whoever would have to clean up a mistake.
It matters because: I cannot set a boundary around access I have not listed.
[The Background]
Here is what you need to know: the AI tools we use are [LIST YOUR TOOLS]. The systems they connect to are [EMAIL, CRM, FILES, CALENDAR, PAYMENTS, OTHER]. The people who use them are [ROLES]. Our business is [WHAT YOU DO].
Do not use: assumptions about tools I did not name.
[The Deliverable]
Return: one table with a row per tool.
Must include: tool name, what it can read, what it can change or send, who can use it, and one line on the worst thing that could happen by accident.
Optimize for: accuracy.
[The Questions]
Ask me any questions you have.
2. Sort everything into read, draft, and act. Three buckets. Then look hard at the third one. For each item in it, either write one sentence justifying why autonomous action is acceptable there, or move it. Most owners move at least two things in this step, and those two moves are the bulk of the risk reduction.
3. Write the never list in your own words. Use your actual information types, not generic categories. Keep it short enough to recite. Then put one sentence next to each item explaining why, because a rule with a reason attached survives a busy Friday and a rule without one does not.
4. Name an approver for each tier, and make sure at least two things come off your desk. If every approval routes to you, you have not built a system, you have built a bottleneck with a document attached. Pick two categories a team member can own, write down the specific error type they must be able to catch first, and train for that one thing.
5. Draft the incident response before you need it. First hour only. Who to tell, what to pause, what to say, what to record. Plus a short customer message template, because the version you write calmly on a Tuesday is dramatically better than the one you write at 9pm while your largest client waits for a reply.
6. Put the whole thing on one printed page and walk your team through it in ten minutes. Not an email. Not a shared folder. A conversation, then the page where people will see it. The document only works if people have read it, and nobody reads the thing that arrives as an attachment.
7. Book thirty minutes next quarter, right now, before you close this tab. Title the calendar event "AI access review." Put the checklist in the event description. Future you will not remember to create this, and a boundary nobody revisits is a boundary that has already expired.
Frequently Asked Questions
Do I really need an AI policy if I only have three employees?
You need the one page more than a large company does, not less. A big company has a legal team to absorb a mistake. In a three-person business, one bad automated email to your biggest client is a material percentage of your revenue, and you are the one who takes the call.
What is the difference between this and the enterprise AI governance I keep hearing about?
Scale and vocabulary, mostly. Enterprise governance adds committees, audit trails, and regulatory mapping. Your version answers the same four questions on one page: what it touches, what it never touches, who approves what, and what happens when something goes wrong.
Is it safe to put client information into AI tools at all?
It depends entirely on which tool and which plan. Paid business plans typically offer different data handling than free consumer accounts, so read what you actually agreed to. The practical answer is to write a classification first, then check whether your tools satisfy it, in that order.
My team is already using AI tools I did not approve. What do I do now?
Start with the inventory, not with discipline. Shadow use is almost always someone solving a real problem the approved tools did not solve. Find out what the problem was, then decide whether to approve the tool, replace it, or address the underlying gap directly.
How often should I update this?
Quarterly, in thirty minutes, with one question that specifically hunts for permissions or integrations added since last time. Also update immediately whenever you add a tool, change who does what, or have an incident. Those three triggers catch almost everything a calendar alone will miss.
The Close
Google has a model that scores 88.2% at finding real software vulnerabilities and it decided you cannot have it yet.
Sit with that for a second, because it is the most useful thing that happened in AI this week and it has nothing to do with the benchmark. The company holding the best tool in the category looked at what it built and concluded that the responsible move was to define, in writing, exactly who gets to use it and under what conditions.
That is not a story about Google being cautious. That is a story about what maturity looks like in this field.
You have the same decision in front of you at a smaller scale, and you have been making it by default. Every week you do not write the page, the page gets written anyway, by whoever on your team needed to get something done this morning. They are not wrong to do that. They have no document to consult.
Give them one.
Candidly, I think this is the single most under-done, highest-return afternoon available to a small business owner right now. Not a new tool. Not a better prompt. One page that says what the machine may do in your name.
The labs figured out this quarter that permission is the control surface. You can figure it out this afternoon.
P.S. If you want the version of this built alongside other owners working through the same thing, that is a lot of what we do inside AI Insiders at $247 a month. But you do not need me to do this one. The four questions are right up there. Go answer them.
About the author
Jonathan Mast is the founder of White Beard Strategies LLC, 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 roughly 500,000 entrepreneurs, the AI Insiders membership, and ongoing live training programs built on the Perfect Prompt Framework 2.0. He has built a seven-figure agency, lost it, and rebuilt, which is a large part of why he would rather you write the boundary down before you need it than after.
