MCP Security: Read Only by Default, Write Access One Action at a Time

MCP connections are as safe as the access they are given. Start every connection read only, add write access one tool and one action at a time, use allow lists for tools whose keys can do everything, require a person's approval before anything is sent, published or spent, and keep a record of what is connected and why.

This is general information, not security or legal advice.

Is MCP secure?

MCP can be used securely, but it is not secure by default in the way a locked door is. It is a standard for connecting AI to tools, and it does not decide what an AI may do. The business makes those decisions through the access it grants, the servers it approves and the checks it keeps.

The scale of MCP use raises the stakes. According to Anthropic, there were more than 10,000 active public MCP servers by December 2025. Not all of them are equally trustworthy, and a connection inherits whatever access it is given.

The good news is that the controls are familiar. They are the same principles applied to any system access: least privilege, approval for consequential actions and regular review.

What are the main MCP security risks?

The main risks are permissions that grow beyond what a job needs, malicious or tampered tools, instructions hidden in data the AI reads, unapproved servers, and too little logging to know what happened. OWASP's MCP Top 10 names each of these, and most trace back to access granted too broadly.

OWASP describes scope creep directly: loosely defined permissions "often expand over time, granting agents excessive capabilities". That is the risk most businesses meet first.

How should MCP access be granted?

Grant access in layers. Start with read only access to the specific data a job needs. Add write access only for named actions, one tool at a time, and prefer actions that create drafts over actions that send or delete. Require a named person to approve anything external or costly.

The principle is least privilege. NIST, the US standards body, defines it as restricting access to the minimum necessary for the task. For AI connections, that means:

1. Read before write. Every new connection starts read only.
2. Named actions only. "Create draft" is granted; "delete" and "send" are not, unless the job truly needs them.
3. Scoped accounts. Connect with an account whose permissions match the job, not an administrator's.
4. Reversible first. Drafts and paused items before anything live.
5. Human at the gate. Approval for anything sent, published, spent or changed in bulk.

The guide to AI agent permissions goes deeper into how to scope access.

Why use an allow list for risky tools?

Because some tools' keys can do far more than any job needs, and some offer no read-only option at all. An allow list sits between the AI and the tool, permits only the specific actions you have approved, and refuses everything else, including new functions a vendor adds later.

A deny list does the opposite: it blocks known risky actions and permits the rest. The trouble is that it admits every new function nobody has thought about yet. An allow list fails closed. When in doubt, it refuses, which is the right way for a guard to fail.

This matters most where actions are irreversible: sending messages from a real person's account, publishing to a website, or changing financial records. For those, the allow list plus a person's approval is the practical safety layer, rather than the tool's own key. The guide to access versus permission explains the distinction.

How do you audit MCP connections?

Keep a register of every MCP connection: what it connects to, which account it uses, what it can read and do, who approved it and when it was last reviewed. Review it every quarter, remove connections nobody uses, check for permissions that crept in, and look at logs of what the AI actually did.

The evidence for regular audit is clear. According to IBM's 2025 Cost of a Data Breach report, 13% of organisations studied reported breaches of AI models or applications, and 97% of those lacked proper AI access controls. A register and a quarterly review are cheap compared with that.

Official guidance supports the same approach. According to the National AI Centre's Guidance for AI Adoption, essential practices include measuring and managing risks, testing and monitoring, and maintaining human control.

Skein connects AI to business tools read only first, uses allow lists for tools that cannot be scoped, and keeps a person approving anything external; the shared knowledge layer page explains the permissions. That suits a business connecting AI to its CRM, inbox or website. A team using AI only on pasted material has little to secure here yet.

Frequently asked questions

What are the security risks of MCP?

The main risks are permissions that expand beyond what a job needs, tools or their outputs being compromised to steer the AI, instructions hidden in content the AI reads, unapproved servers and too little logging. OWASP's MCP Top 10, currently in beta, lists these and related risks.

How do you secure an MCP connection?

Start read only, add write access only for named actions one tool at a time, connect with a scoped account rather than an administrator's, use allow lists for tools whose keys can do everything, require human approval for external actions, and audit connections every quarter.

What is tool poisoning in MCP?

OWASP describes tool poisoning as an adversary compromising the tools, plugins or their outputs that an AI relies on, injecting misleading context to steer its behaviour. Using only approved servers, tracking changes to tools and requiring approval before consequential actions reduce the risk.

Should AI have write access through MCP?

Only where a specific job needs it, and only for named actions. Start every connection read only. When write access is needed, prefer actions that create drafts or paused items, and keep a person approving anything sent, published, spent or changed in bulk.

What is an allow list for AI tools?

An allow list permits only the specific actions you have approved and refuses everything else, including functions a vendor adds later. It suits tools whose access keys allow far more than any job needs, because it fails closed rather than letting unknown actions through.

Related reading