Do You Have an AI User Policy? Four Tiers of Risk, and How to Write One
Here is something most firms do not know, and it is not a technical fact.
If you prepare tax returns, you are a financial institution under federal law. Not a bank. Not an investment firm. A financial institution, in the plain text of the Federal Trade Commission’s Safeguards Rule — the rule that requires you to have a written information security program, to encrypt client information, to require multi-factor authentication, to train your people, and to oversee every service provider that touches customer data.
That is not new. The Safeguards Rule was rewritten in December 2021, and amended again in November 2023. It has never needed an AI-specific statute to apply.
Here is what is new. Every service provider your firm now uses has to be selected, contracted, and periodically reassessed under that rule. And somewhere in the last eighteen months, your staff adopted AI tools — a chat window, a connected assistant, a plugin, a coding agent on someone’s laptop. Those tools are service providers now. The rule that was always on the books quietly grew a long list of members, and nobody had to amend it to do it.
Meanwhile most firms have no AI policy at all. Not a bad one. No one.
The gap between those two facts is where the risk lives. So let me make this practical. There are four tiers of AI exposure, they are not equally dangerous, and each one has a different answer.
Tier 1: The Chat Window
This is the simplest case and the one most people mean when they say “AI.” Someone opens a web chat, pastes in a question, gets an answer back. No plugins, no connections, no access to anything.
The risk here is entirely about what happens to the text you paste.
On a personal ChatGPT account, data sharing is enabled by default. OpenAI calls the setting “Improve the model for everyone,” and it is on unless someone turns it off. On a personal Claude account, Anthropic’s terms work the other way — consumer chats and coding sessions are used to improve their models only if you choose to allow it, though that choice has a wrinkle: hit the thumbs-up or thumbs-down button on any conversation and Anthropic stores the whole thing for up to five years.
Neither company is doing anything wrong. The settings simply are not what a business needs.
The fix is not a reminder. It is an account tier. Business and enterprise account tiers are a different contract, with different defaults. OpenAI states it does not train on business data by default, and that covers ChatGPT Business, Enterprise, Healthcare, Edu, and Teachers, plus its API. Anthropic’s commercial terms say flatly that it may not train models on customer content from its services. Microsoft says the same for Microsoft 365 Copilot — prompts, responses, and data accessed through Microsoft Graph are not used to train foundation models.
Tier 1 rule: personal accounts are for personal work. If client information touches a chat window, it is an enterprise account, on a company-controlled tenancy, with training off and the setting verified rather than assumed.
Tier 2: The Connected Cloud
Now the assistant can reach into your environment. Microsoft 365 Copilot reads mail, files, chats, and calendars through Microsoft Graph. Enterprise ChatGPT apps pull from connected sources. This is genuinely useful, and it is a different risk class from Tier 1.
Training is mostly solved here, because enterprise contracts handle it. The new problem is scope. The assistant surfaces whatever the signed-in person can see. If your SharePoint permissions are a mess, your AI assistant is a very fast way to find out.
And the structural risk of this tier is now documented and exploited. In June 2025, Microsoft assigned CVE-2025-32711 to an AI command injection flaw in Microsoft 365 Copilot — rated 9.3 Critical, and exploitable with no user interaction. The finding, known as EchoLeak, allowed an attacker to disclose organizational data over the network. A crafted email was enough; nobody had to click anything. The researchers who found it published their write-up under the title “EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System.”
Security researcher Simon Willison named the underlying condition in June 2025: the lethal trifecta. An agent becomes dangerous when it combines private data it can read, untrusted content it will process, and a channel to send information outward. Any one of the three is survivable. All three at once is a path for anyone who can write text the agent reads.
Tier 2 rule: the assistant reads what the person reads, so the assistant inherits the weakest permission in your estate. Before connecting it to anything, fix the permissions. Then scope it: which data sources, which people, which actions.
Tier 3: The Skills and Connectors
This tier starts to sound exotic, and then you install a plugin and remember that plugins are code you did not write, running with your permissions.
The Model Context Protocol, or MCP, is the standard that lets assistants connect to external tools — a ticketing system, a file share, a billing database. It is genuinely useful and it is a supply chain, in the same way that every package manager is a supply chain.
There are real incidents. CVE-2025-34072 covers a data exfiltration vulnerability in Anthropic’s deprecated Slack MCP server, exploitable through automatic link unfurling: an agent processing untrusted data could be manipulated into generating messages containing attacker-crafted links embedding sensitive data, which the preview bot then fetched for the attacker. That server was deprecated and unmaintained, which is itself the lesson — an MCP server is a dependency, and dependencies rot.
The pattern is called tool poisoning, and it works like this: instructions hidden in a tool’s own description, where the model reads them as part of its instructions rather than as data. You installed a tool. It read your other tools. It phoned home.
Tier 3 rule: a skill, plugin, or MCP server is third-party code with your access. It gets the same review as any other software you deploy — who published it, what data does it touch, does it need outbound network access, who is accountable when it misbehaves. No exceptions for the fact that it was one click to install.
Tier 4: The Desktop and the Browser
This is the tier that should worry you most, and the one people adopt fastest.
An agentic coding tool runs on your primary machine. It reads your files. It has a browser session with your live credentials — your email, your banking portal, your client portal, your tax software. It does not ask permission to open a browser tab; it asks permission to send an email, or sometimes it does not ask that either.
The risk is not that the tool is evil. It is that the tool is obedient to anything it reads. A page on a site your agent visits can contain instructions. In the EchoLeak case, the instruction arrived by email. It can arrive by web page instead. Once an agent has your logged-in browser session and processes untrusted text, the trifecta is fully assembled.
Anthropic’s own security research has documented Claude writing a working exploit chain that gets arbitrary code execution outside Chrome’s sandbox — the proof of concept launches the Calculator app on a stock Mac Chrome build within seconds of the page loading, with no further user interaction. It also found a chain that let any website’s JavaScript bypass the same-origin policy in Safari, which means an attacker could read a signed-in user’s email. The point for your firm is not that Claude is dangerous. The point is that a webpage an agent visits is executable content, and a general-purpose coding model wrote that chain from initial prompting.
Tier 4 rule: this tier does not get a policy clause. It gets a sandbox. A separate machine or profile, no live production credentials, no access to the file share, and a human confirming anything irreversible. If a tool cannot be confined, it does not get installed on the machine that holds the books.
The Rule You Already Have to Follow
Here is the part I want to be precise about, because most advice on this topic treats the law as something that does not exist yet.
If your firm prepares tax returns or provides certain financial services, the FTC Safeguards Rule (16 CFR Part 314) already applies to you. It is activity-based, not title-based — what matters are the types of activities your business undertakes, not what you or others call your company. For a tax-preparation firm, the regulation does not leave that to interpretation. 16 CFR 314.2(h)(2)(viii) says:
An accountant or other tax preparation service that is in the business of completing income tax returns is a financial institution because tax preparation services is a financial activity listed in 12 CFR 225.28(b)(6)(vi) and referenced in section 4(k)(4)(G) of the Bank Holding Company Act, 12 U.S.C. 1843(k)(4)(G).
The Rule then requires a written information security program containing nine elements. Those elements include designating a Qualified Individual to run the program, conducting a risk assessment, implementing access controls and encryption, requiring multi-factor authentication, training personnel, and overseeing service providers.
That last element is the one that matters for AI. It breaks into three specific duties:
- Take reasonable steps to select and retain service providers capable of maintaining appropriate safeguards.
- Require your service providers by contract to implement and maintain such safeguards.
- Periodically assess those providers based on the risk they present.
One thing worth being clear about, because it gets misstated: your AI vendor is a service provider under the Rule’s definitions, but that does not make it directly subject to the Safeguards Rule itself. The obligations run to you, as the covered institution. Your job is to select, contract with, and reassess.
That includes your managed service provider. If Nerdworks Services — or any MSP — holds your network, your email, and your file share, you are the covered institution and they are the service provider, which means you need a contract requiring safeguards and a schedule for reassessing them. If your firm is also a service provider to other covered firms, you wear both hats, and the obligations run to you in both directions.
There is a second hook in the same Rule that fits AI tooling even more precisely, and it rarely gets mentioned. 16 CFR 314.4(c)(4) requires covered institutions to adopt secure development practices and to maintain “procedures for evaluating, assessing, or testing the security of externally developed applications you utilize to transmit, access, or store customer information.” Read that again with an MCP server in mind instead of a payroll application. A skill, a plugin, a connector, an agentic coding tool — that is an externally developed application, and if it touches customer information you are already required to have a documented procedure for testing its security before you rely on it. The regulation does not say “AI.” It does not need to. Your Tier 3 review process is a Safeguards Rule requirement you already owe.
Now the part that catches people. There is an exemption for financial institutions maintaining information on fewer than 5,000 consumers — and it is narrower than it sounds. It applies only to four specific paragraphs: the written risk assessment, the specific monitoring and testing cadence, the written incident response plan, and the annual written report. Service provider oversight is not on that list. Nor are encryption, multi-factor authentication, access controls, training, or breach notification. A twelve-person CPA firm with hundreds of clients still owes the full service-provider duty.
There is one more duty in the Rule that is worth knowing even though it is separate from the nine elements. Since May 2024, a covered institution must notify the FTC of a “notification event” — a breach involving the unauthorized acquisition of at least 500 consumers’ unencrypted information — as soon as possible and no later than 30 days after discovery. An AI tool that leaks a client file is not a special case; it is a security event like any other, and it runs on the same clock.
So the enforcement mechanism you are looking for is already in a rule you are already subject to. You do not need to invent a new AI-specific law to know what to do. A well-written AI user policy is a service-provider oversight artifact. It is the document that shows you selected capable AI providers, required safeguards by contract, and periodically reassessed them.
Two more pieces of the frame. The EU AI Act Article 4 has applied since February 2025, and it was amended in July 2026 to require you to “take measures to support the development of AI literacy” among staff — with the amendment expressly stating that it does not require you to guarantee any particular individual’s literacy level. Article 50’s transparency obligations apply from August 2026. If you deploy AI systems in the EU, which can include work you do for EU clients, your AI policy is now partly a transparency document. And the NIST AI Risk Management Framework with its Generative AI Profile (AI 600-1) is voluntary, but it is the best structure I have seen for writing one: Govern the policy and assign ownership, Map the systems and their context, Measure the risks, Manage the response. If your policy does not have those four verbs in it, it is not going to survive contact with an incident.
If you are in Texas, that framework is worth a second look. The state’s Responsible AI Governance Act took effect January 1, 2026. It creates a rebuttable presumption that a person used reasonable care, and it gives you four ways to discover a violation — including testing or red-team testing, and including substantial compliance with the most recent NIST Generative AI Profile combined with an internal review process. Discover it and you get a chance to cure it; do not, and the penalties run from $10,000 to $12,000 per curable violation, $80,000 to $200,000 per uncurable one, and $2,000 to $40,000 per day for a continued violation. On complaint, the Texas Attorney General can issue a civil investigative demand asking for your AI system’s purpose and intended use, the data it processes, the outputs it produces, the metrics you use to evaluate it, its known limitations, and your post-deployment safeguards. “A reasonable care record is the defense.”
For healthcare clients, the question is whether a Business Associate Agreement is in place with the AI vendor before any protected health information goes in — and note that a vendor’s BAA does not automatically cover features like browser use or local execution, and that the AI vendor is itself directly liable for certain HIPAA provisions when it acts as a business associate. For everyone else, remember that the FTC’s enforcement theory on AI marketing claims has been active since Operation AI Comply in September 2024, and an AI policy that promises capabilities the tool does not have is a deception problem wearing a compliance costume.
What the Policy Actually Says
Eight clauses. This is the whole document.
- Name the tiers. Paste the four-tier structure above into the policy. The tier is the risk level, and the tier determines the rule.
- Assign an owner. One named person, the counterpart to your Qualified Individual. Not “IT.” Not “the business.”
- Set the account tier for each risk tier. Consumer accounts prohibited for client data. Which enterprise account is approved for each risk tier, and who buys it.
- Name the data classes. What can go in, what cannot, and what must be redacted first. Client financial records and credentials are almost certainly out at every tier.
- Require human approval for irreversible actions. Sending, buying, deleting, publishing, filing. The bot drafts; a person clicks. Every time.
- Define the connection rules. Which data sources an assistant may reach, which it may not, and what happens when permissions are wrong.
- Require a review for third-party skills. Publisher, data touched, outbound network access, accountable owner. The same review you give a new vendor.
- Require an annual review of the policy and the tools. Both, together. The tools change faster than the law does.
That is the document. It is not long, and it should not be — a policy nobody reads is decoration.
The Five Questions to Ask Today
- Which AI tools are actually in use right now, and on which tier? Ask plainly, including the ones on personal phones. The gap between what is approved and what is in use is the real exposure.
- Has client information ever been pasted into a personal account? If yes, you have a specific incident to handle, not a policy to write. Decide what you are doing about it.
- Who has a tool that can reach our file share, our email, or our billing system right now? One name is an answer. “A few people” is not.
- Does anyone have an agent on a machine that holds live production credentials? If yes, that is the most urgent item on this list, and it is not a policy question — it is a configuration question.
- If a client asked tomorrow what our AI policy says, could we hand them the document? If the honest answer is no, we have already answered their question about how seriously we take their data.
If any of those five answers is “I am not sure,” that is the conversation to have this week — not a year from now, because the tools are already in use.
If you want to handle it internally, start here. Pick one person to own it. Write the eight clauses. Put the tier structure on one page. Then walk the list of tools your firm actually uses and write the tier next to each one, so the policy and reality agree. That is the whole exercise, and it takes an afternoon.
And if you do it for someone else, do it with them. The firms that get this right are not the ones with the best policy. They are the ones where the policy and the tooling were reviewed together, in the same week, by the person who owns both. That conversation is worth more than any template, because it protects the business from the day somebody pastes a client ledger into a chat window.
If you want a second set of eyes on this, book a discovery call. We will look at what your team is actually running, what it can reach, and where the gaps are — no obligation, and no jargon.
Sources: FTC Safeguards Rule (16 CFR Part 314) — definitions, requirements, and smaller-entity exceptions; FTC Safeguards Rule guidance; NIST AI 600-1 Generative AI Profile; Texas HB 149 (TRAIGA); NVD records for CVE-2025-32711 and CVE-2025-34072.
Nerdworks Services, LLC | 1901 Central Drive, Suite 401, Bedford, Texas 76021 | (682) 324-9360 | website: https://nerdworks.services/ | email: [email protected]