# MCP security risks come from one combination, and a team's notes supply two parts of it

> Is MCP safe to use? It is as safe as the servers you connect. How to check one against the lethal trifecta, and why a team's shared notes change the answer.

Source: https://baalda.com/blog/is-mcp-safe
Site: Baalda, https://baalda.com
Published: 2026-10-18

**Short answer.** MCP is as safe as the servers you connect to it. The serious risk is one combination: an assistant with your private data, text an attacker wrote, and a way to send data out. Check each server for which of those it supplies and who decides its reach. A team's shared notes bring the first two.

MCP is as safe as the servers you connect to it, and no safer. The protocol itself is a message format between an AI client and a tool server. What decides the risk is what those servers can read, what they can send out of the building, and whether text an attacker controls can reach the model in between.

Most answers to this question stop at "it depends what you connect" and hand you a checklist: use popular servers, prefer the official list, guard your tokens. That advice is fine as far as it goes. It does not tell you how to judge a particular server, and it says nothing about the case most teams actually have, which is an assistant connected to notes that several people write.

## Is MCP safe to use, or is the protocol the problem?

The specification is clear that the protocol does not make a tool call safe on its own. The [tools page of the MCP spec](https://modelcontextprotocol.io/specification/2025-06-18/server/tools) says that "there **SHOULD** always be a human in the loop with the ability to deny tool invocations", and that clients "**MUST** consider tool annotations to be untrusted unless they come from trusted servers." Its security list puts the hard work on the server, which "**MUST**" validate inputs, "Implement proper access controls", rate limit calls and sanitize outputs.

So the honest answer has two halves. The client is responsible for asking before it acts. The server is responsible for what an action can reach. A safe setup needs both, and the checklists mostly cover the first.

## What are the real security risks of MCP?

The clearest framing is Simon Willison's [lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/), published on 16 June 2025. An agent is exploitable when it has all three of these at once:

1. **Access to your private data.**
2. **Exposure to untrusted content**, meaning any text an attacker could get in front of the model.
3. **The ability to externally communicate** in a way that could be used to steal that data.

Any two are manageable. All three together mean a line of text the attacker wrote can tell the model to read something private and send it somewhere. Willison names MCP directly as the place this happens, because it "encourages users to mix and match tools from different sources". One server brings the private data, another brings a web page, a third can send an email, and no single vendor is in a position to stop the combination.

The other risks the checklists list are real but narrower. Poisoned tool descriptions, leaked tokens and over-broad scopes are each a way of handing one of those three legs to someone you did not mean to. The spec's own [security best practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices) covers the server-side ones, from token passthrough, which it forbids outright, to scope design, where it warns that "Poor scope design increases token compromise impact."

## Why is a shared notes server a special case?

Connect an assistant to your own notes and the untrusted-content leg is mostly about what you paste in. Connect it to a team's notes and every note somebody else wrote is content you did not write. A meeting summary a colleague pasted from a customer email, a PDF someone uploaded, a page an automation filed overnight: the model reads all of them with the same weight as your own words.

There is a second difference. In a shared vault, writing a note into a folder other people can open is a way of getting data out. It never leaves the building, but it leaves you. An injected instruction that copies a private note into a shared one has exfiltrated it to everyone with access to that folder.

That means the useful question about a notes server is not "is it popular". It is which of the three legs the server itself supplies, and who decides how far each one reaches.

## How do you check a server against the trifecta?

You can answer this for most servers from their tool list, without reading their code. Here is what to look for, using [Baalda](/), a team second brain whose MCP endpoint is part of its own server, as the worked example. The figures come from its server source as of 14 October 2026, `apps/server/src/mcp/tools.ts`.

**The way out.** Look for any tool that fetches a URL, sends a message or calls another service. Baalda's endpoint exposes 23 tools, and every one of them is a vault operation: list, read, search, create, edit, move, delete, and a handful for access. None makes a network request, and every tool declares the spec's `openWorldHint` as `false`:

```ts
const READ: Hints = { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false };
```

That does not remove the external-communication leg from your setup. It means this server does not supply it, so the leg can only come from another tool your client has loaded.

**The private data.** Look at whether the server answers as a person or as a key that sees everything. A Baalda token, or an OAuth grant from a connector, resolves to one user in one vault, and the read tools are filtered by that user's per-file permissions on every call. `list_notes` and `search_notes` only return notes the user can open, and `read_note` refuses the rest with "You do not have access to this note". Share the finance folder with three people and the other seven's assistants cannot read it, list it or find it in search. The same rule is how [per-file permissions work in the app](/blog/obsidian-per-file-permissions), not a separate MCP setting.

**The untrusted content.** This is the leg the same permissions narrow from the other side. An assistant can only read what its user can read, so the set of people whose writing reaches your model is the set of people who can write into folders you can open. A private folder nobody else edits is, for prompt injection, as safe as your own notes. A folder the whole company edits is not.

**The writes that matter most.** Look for tools that change who can see what, and check who may call them. Baalda has two, `manage_access` and `set_access_default`. Both are owner and admin only, and both are annotated `destructiveHint: true`, which is the signal a client uses to ask before running them. Every access change also lands in an audit history with its actor and before-and-after values, which an owner or admin can read back through `list_access_audit`. The full list, with what refuses each call, is on the [MCP tools docs page](/docs/mcp-tools).

## Where does a server like this stop protecting you?

There are four places, and they matter more than the parts above.

**It does not detect prompt injection.** Nothing in Baalda reads a note and decides it is hostile. If a colleague's note contains an instruction and your assistant follows it, the server sees an ordinary, permitted tool call from you.

**The token acts as you.** There is no per-token scope that narrows one connection to read-only or to one folder. An assistant holding an owner's token can call `manage_access`, so the destructive annotation, and a client that honours it, is what stands between an injected instruction and a folder shared with everyone. The audit history records that change under your name, because as far as the server can tell it was you.

**Shared folders are still a way out.** Your assistant can write into any folder you can edit. If you can edit a folder ten people read, so can a model following someone else's instructions.

**The client's other tools are out of sight.** A server can only answer for its own catalog. If the same client also has a web fetch, a browser or an email tool loaded, the trifecta is complete again, and no notes server can see that. This is the same reason Notion's connector is worth reading closely: [connecting Claude to Notion](/blog/can-claude-connect-to-notion) hands it every page you can open, and what else is loaded beside it decides what that means.

## So is it safe to connect an assistant to your team's notes?

Yes, with the trifecta in mind rather than a list of brand names. Keep the private notes in folders few people write. Leave a tool that reaches the internet out of the same session as one that reads the vault, or make sure the client asks before every call it makes. Keep owner tokens for owner work. And prefer a server that answers as a person, with permissions you can read, over one that holds a single key to everything, which is the argument for [running the server your team's notes live on](/blog/local-mcp-server-your-team-vault) rather than a process on each laptop.

MCP did not invent any of these risks. It made it very easy to put all three legs in one place without noticing, which is the one thing worth checking every time you add a server.

## FAQ

### Is MCP safe to use?

Safe enough, if you judge each server rather than the protocol. MCP is a message format between a client and a tool server, and its specification puts the safety work on both ends: the client should keep a human able to deny a tool call, and the server must enforce access controls on what each call can reach. A setup is risky when the servers in one session together give the model private data, untrusted text and a way to send data out.

### What is the lethal trifecta in MCP?

It is Simon Willison's name, from a post on 16 June 2025, for the three capabilities that make an agent exploitable when they appear together: access to private data, exposure to untrusted content, and the ability to communicate externally. MCP makes the combination easy because one session can load servers from several vendors, each supplying one part, and none of them is in a position to see the whole.

### Can a prompt injection in a shared note affect my assistant?

Yes. When an assistant reads a note, it reads the note's text with the same weight as your own instructions, whoever wrote it. In a shared vault that includes colleagues, pasted emails, uploaded documents and anything an automation filed. Baalda does not detect injected instructions. What it does is limit whose writing reaches your assistant to the people who can write into folders you can open, through the same per-file permissions the app uses.

### Does Baalda's MCP server limit what an assistant can do?

It limits it to what the connected person can do. A token or OAuth grant resolves to one user in one vault, the list, search and read tools return only what that user can open, and the two access-changing tools are owner and admin only and marked destructive. There is no per-token scope yet, so a connection cannot be narrowed below the person it acts for.

### Are local MCP servers safer than remote ones?

Not automatically. The spec's security guidance warns that a local server runs with your own account's reach on your machine, while a remote one moves the trust to whoever operates the server. What makes either safe is the same check: what the server can read, whether it can send anything out, and whether a call is answered as a named person with limits you can inspect.