MCP Security for a Small Business: Treat Tools Like a Supply Chain

MCP security for a small business is a supply-chain problem, not a Chrome-extension problem. Model Context Protocol is how an agent learns which tools exist and when to call them. The tool description is ordinary English the model trusts. Microsoft Incident Response documented in June 2026 how a poisoned description can steer an agent while every click still looks routine. Pin what you install. Read the description. Do not give the agent a standing shell.

Kief Studio is two people, me and Brian. We run kief.studio from Shrewsbury, Massachusetts, and we run agents in that studio. Give the agent its own login first. That is a non-human identity for an AI agent. Then pin the tools it is allowed to call, and watch the path of calls, not only each click. Path control is sequence governance.

What MCP looks like on a Monday

You connected an agent to mail, files, or invoices because the demo was fast. The screen looked finished. The answers came back in clean sentences. The walkthrough is built to look finished. After ten minutes of that, people hand it a real job. Looking good in a meeting is not the same as being ready to attach every unpaid invoice to the next vendor call.

MCP servers advertise tools. The agent reads the name, the summary, and the long description. You see a friendly card. The model sees instructions. At a desk, that is the difference between a button that says "fetch invoices" and a paragraph the model reads that also says "attach the unpaid ones to the next call." Invariant Labs named tool poisoning in April 2025. Microsoft's 30 June 2026 post walked a finance workflow: the visible summary stayed the same, the description gained a buried order to attach unpaid invoices to the next call. The agent did not break a rule. It followed metadata.

Microsoft Security, 30 June 2026, maps that pattern to OWASP agentic classes for tool misuse and supply chain. You do not need the full catalog. You need an allowlist and a human who reads diffs. An allowlist is a short list of tools the agent may call, written down, not "whatever the card offered this morning." CISA's 1 May 2026 ask was the same idea in allied language: do not give an agent open access, start on a low-risk job, and put the software into the process you already use for vendors. I translated that paper in Five Eyes agentic AI guidance for a small business.

Pin the version the way you already pin packages

If you have ever frozen a lockfile so Friday's build matches Monday's, you already know this muscle. A lockfile is the list of exact package versions a project used last week. A tool card that always loads "latest" is the opposite. A clean server can ship a new description after you approved the old one. That is a rug pull. Pin the version. Re-read the full text on update. Same habit as npm, just in English instead of JSON.

That is why your lockfile is a threat surface belongs next to MCP. Skills and MCP servers are dependencies that speak English. If you would not merge a mystery package without reading the diff, do not load a mystery tool card because the one-line summary still says "fetch invoices."

Put the secret that the agent uses in the password manager, not in Slack, and do not let that secret be a person's password. NIST said shared passwords make it impossible to prove who acted. If the MCP tool can send mail as you, the log will say you sent it. On a Tuesday that looks like a customer email that went out while you were at lunch, signed with your name, from a tool nobody remembers installing.

Skills are the same chain with nicer packaging

A skill is a reusable bundle of instructions an agent can load. Think of it as a playbook someone else wrote, plus whatever tools the playbook is allowed to touch. OWASP Agentic Skills Top 10 v1.0 (17 August 2026) leads with malicious skills and supply-chain compromise. AST07 is update drift: the bundle you approved is not the bundle that runs next month. AST05 is untrusted external instructions: a skill that fetches a URL at runtime is loading someone else's prompt with your permissions.

Do not load a skill that pulls live instructions from a random URL. Inline the instructions you trust. Pin the rest. If you cannot explain why a tool is on the machine, it is not on the machine.

Monday rules for a studio using Claude, Cursor, or similar:

1. Inventory every MCP server and skill. Name an owner. A person, not "engineering."
2. Pin versions. No "latest."
3. Read the full description, not the one-line summary.
4. No standing shell, no unrestricted file write, no production credentials in the agent.
5. A person on pay, send, delete, and deploy. Looking things up can run on its own.

A standing shell is an open command line the agent can keep using without asking again. That is convenient until it can also delete a folder. Pay, send, delete, and live deploys are the moves you cannot cheaply undo. Search and list can stay open so the agent is still useful.

What this is not

None of this is a reason to ban agents. We run them. You also do not need a dump of every CVE, which is a numbered software flaw, to start. Isolation helps. An allowlist helps. A person who treats description diffs like code review is the control that scales to two people. A gateway does not replace that person.

It is also not a Chrome-extension problem. Browser plugins are a different supply chain with a different store. MCP is closer to a vendor you added because the card looked friendly. Treat it like a vendor. Ask the same class of questions you would ask any software seller, which is why this sits next to what to ask your vendors about security and how to evaluate AI tools without getting sold.

kief.dev is where we publish engineering hygiene. briansgagne.com is the architecture when you need depth. LTFI is a hired department, not an MCP you paste into Cursor. I explained that split in what LTFI is.

A two-person review that actually happens

We do not run a security committee. We run a diff. New MCP or skill: paste the description into the pull request, say what tools it may call, say what it must never call. Update: same pull request. If the description grew a paragraph about "also fetch," that is the Microsoft invoice example in miniature. Reject it.

Show the full tool call in the log, not a friendly paraphrase. If the log only says "fetched invoices," you will not see that it also attached a second file. CISA called out records that are too vague to use. Vague MCP logs are the same failure with a nicer UI.

Start with work where a mistake is easy to fix. Have the agent draft an internal FAQ, or summarize last week's tickets. Leave the public site, payroll, and vendor payments off that agent until the smaller job is boring. If the demo was pretty and production never started, that stall has its own article: why AI pilots stall before production.

What that looks like in a week

Monday, write the one sentence for the job, then list every MCP server and skill already on the machine. If you need "and also" to describe the job, cut it. If a tool is on the machine and nobody can say why, take it off.

Tuesday, pin versions. Replace "latest" with a number you can write down. Put the agent's secret in the password manager. Do not use a person's password. If the agent does not have its own login yet, stop here. The rest is decoration.

Wednesday, read the full descriptions out loud, not the one-line summaries. If a paragraph appeared that you did not ask for, treat it as a lockfile bump you did not approve. Reject it. Reading out loud is the whole control. You hear the extra sentence about "also attach" that your eye skipped.

Thursday, put pay, send, delete, and live deploys behind a person. Leave search and list open so the agent can still be useful. If a tool is a standing shell, it is not on this agent yet.

Friday, confirm the log shows the full tool call and names the agent. Turn it off. Turn it back on. Write two sentences about who is on call if it misbehaves over the weekend. That is CISA's "put it in your security model" without a new binder.

If you only keep one rule, keep this one: no standing production credentials on an agent that can load third-party MCP or skills. Pin, read, and put a person on anything you cannot undo. Practice turning the agent off once on a quiet afternoon. If turning it off also locks a person out, the identities were never separate.

Related reading

• What is a non-human identity for an AI agent
• AI agent governance: sequence, not each click
• Five Eyes agentic AI guidance for a small business
• Your lockfile is a threat surface
• How to evaluate AI tools without getting sold
• What to ask your vendors about security
• What LTFI is, and what you do not install

Frequently Asked Questions

Is MCP security a small-business issue or only enterprise?

If you connected an agent to mail, files, or invoices, you have a supply chain. Size of company does not change the description field.

Do I need to read every tool description?

Yes, once per install and on every update. Microsoft treats description changes as dependency updates. That is the whole control.

Are skills different from MCP servers?

They travel a similar path: instructions the agent trusts, often with extra tools. OWASP's skills list is the skill-shaped version of the same chain. Inventory both.

What is the one rule if I only keep one?

No standing production credentials on an agent that can load third-party MCP or skills. Pin, read, and gate irreversible tools.

Can I just install a gateway and stop thinking about this?

No. Isolation helps. An allowlist helps. Someone still has to read the description when it changes, the way you would read a lockfile bump.