Someone in your office watched a two-minute video about getting more out of their AI assistant. The video linked a GitHub page. The page had setup instructions: install this connector, drop this text file into that folder, restart. Ten minutes later the assistant can read their email, search the shared drive, and draft replies on its own.
It works exactly as promised. That is the problem.
What just happened is not the same as installing an app. Your staff member granted an automated agent standing permission to act inside your systems, using software written by a stranger and instructions they cannot fully read. And unlike a rogue app, nothing in your antivirus, your firewall, or your email filter is looking at any of it.
What is actually being installed
Two things, usually together, and they carry different risks.
The first is a connector — commonly built on the Model Context Protocol, or MCP, an open standard that lets AI assistants plug into outside tools and data. An MCP connector is what lets an assistant reach your calendar, your inbox, your file storage, or your practice management system. It is real software, it runs on the machine, and it typically inherits whatever access that user already has.
The second is an instruction file — usually plain Markdown, a .md file, sometimes called a rules file, a skill, or a configuration. It tells the assistant how to behave: what to prioritize, what format to use, what steps to follow. It contains no executable code at all. Most people therefore treat it as harmless documentation.
That assumption is the vulnerability. An AI assistant does not distinguish between instructions written by you and instructions it finds in a file. Both arrive as text, and both get followed.
This is not hypothetical
Two published incidents show both halves of the problem.
A one-line change in a connector
In September 2025 a package called postmark-mcp was published to npm, the standard repository developers pull software from. It was an MCP connector that let AI assistants send email, and it was a near-exact copy of a legitimate library. For fifteen versions it did precisely what it advertised. It got recommended in team chats. It accumulated roughly 1,500 weekly installs.
Version 1.0.16 added one line. Every email sent through that connector was silently blind-copied to an address the author controlled.
Password resets. Invoices. Internal memos. Customer correspondence. Koi Security flagged the behaviour later that month, and the package was pulled after around 1,643 downloads. Postmark, the company whose name it borrowed, confirmed publicly that it had neither built nor authorized it.
Security researchers described the backdoor as embarrassingly simple. That is the uncomfortable part. It required no sophisticated exploit — just one line inside a tool that had already earned trust, running with permissions nobody was reviewing.
Invisible instructions in a text file
The second case is stranger and, for a small practice, more relevant.
In March 2025, researchers at Pillar Security published a technique they called the Rules File Backdoor. They demonstrated that malicious instructions can be embedded inside the instruction files AI assistants read, using Unicode characters that render as nothing at all — zero-width joiners, bidirectional text markers. The file looks like ordinary documentation in any editor. The AI reads the hidden text and follows it.
In their demonstration, the payload told the assistant to insert a malicious script into generated output, and to say nothing about having done so. Both instructions were obeyed.
These files get shared the way recipes do — posted on forums, published to GitHub, copied into project templates, passed between colleagues who found something that worked. A poisoned one propagates by being useful.
Pillar disclosed the technique to Cursor in February 2025 and to GitHub in March. Both responded that reviewing what an AI assistant produces is the user's responsibility. Read that as the vendors' position on liability, because that is what it is: the person who installed it owns the outcome. In your practice, that is you.
Why this evades everything you already have
The controls most small practices rely on were built for a different problem.
- Antivirus scans for malicious code. An instruction file contains no code. There is nothing to match against.
- Email filtering inspects messages. This arrives through a browser, a package manager, or a copy-paste.
- Your firewall sees normal traffic. The connector uses the same services the staff member already uses, from the same machine, with the same credentials.
- Approval workflows never trigger. Nobody filed a request. From the user's perspective they configured a setting, not installed software.
- Review does not help if the text is invisible. Someone can read the whole file carefully and see nothing wrong.
There is a further wrinkle specific to how these tools work. Once a connector is approved, the assistant may use it repeatedly without asking again. The staff member consents once, to something that looked reasonable, and the agent then acts on their behalf indefinitely.
The delivery method is the clever part
Traditional phishing has to overcome suspicion. This does not. It arrives as generosity.
Someone shares a setup that genuinely improves their workday, in a community built on that kind of sharing. The recipient is not being tricked into clicking a suspicious link — they are following advice from a helpful stranger, on a platform where helpful strangers are the point. The material is often good. It may well have worked as advertised for hundreds of people before the version that did something else.
Consider who in your practice is most likely to go looking. It is rarely the least engaged person. It is the one trying to get more done, who found their tools frustrating and went hunting for a better way. Your most motivated employee is your most likely entry point, and their instinct is a good one. That is what makes a blanket ban both unfair and useless — it pushes the behaviour onto personal devices and personal accounts, where you have no visibility at all.
Why a regulated practice cannot treat this as an IT curiosity
If you are a medical practice, a law firm, or a financial services company in New York, the exposure is not only operational.
A connector that reads your email is handling protected health information, privileged communications, or client financial data, depending on your practice. Under HIPAA, a vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate — and disclosing PHI to one without a Business Associate Agreement is itself a violation, regardless of how carefully that vendor handles the data. Nobody publishing a connector on a code repository is going to sign one.
New York's SHIELD Act requires a reasonable security program covering administrative, technical, and physical safeguards for private information. A program that has no position on what software staff may connect to systems holding that information has a gap in it, and the gap is now a documented attack vector rather than a theoretical one.
For attorneys, there is the further question of whether client confidences have been disclosed to a third party without informed consent. That is not an IT question at all.
The question a regulator or an insurer will ask is not whether you were breached. It is whether you had a documented position on this before it happened.
What to actually do
None of this argues for banning AI. It argues for treating AI connectors and instruction files as what they are: software that runs inside your practice.
- Find out what is already installed. Ask directly, without blame — you want honest answers, and staff who fear discipline will simply stop telling you. Assume the answer is not zero.
- Write down which AI tools are approved, and be specific about the account tier. Consumer and free tiers of many products reserve the right to use submitted content for training and will not sign a data protection agreement; the business tier of the same product often will. The tool being approved is not enough — the account has to be the practice's.
- Name what may never be entered into any AI tool. Patient identifiers. Privileged communications. Account numbers. Credentials, in any tool, ever. Vague guidance produces inconsistent behaviour.
- Require approval before any new connector is installed — and make that route genuinely fast. A slow approval process is the single biggest reason staff install things without asking.
- Treat instruction files as executable. They come from somewhere, they change behaviour, and they should be reviewed and version-controlled like any other operational configuration.
- Prefer official sources over a repository someone linked in a video, and check whether the vendor whose name is on it actually publishes it. In the postmark case, they did not.
- Add AI tools to your vendor review. If a connector touches regulated information, it belongs in the same inventory as your billing company and your cloud backup.
- Make reporting safe. Someone who realizes they pasted something they should not have will only come forward if the response is proportionate. An overly punitive policy buys you silence, not compliance.
The bottom line
For twenty years the rule was: do not install software you did not get from a trusted source. That rule still holds. What has changed is that the thing being installed no longer looks like software. It looks like a settings file, shared by a helpful person, that makes a frustrating tool work better.
Your staff are not being reckless. They are being resourceful with tools nobody gave them rules for. Writing those rules down is a smaller job than most practice managers expect, and it is considerably smaller than explaining to a regulator why you did not.