What MCP Actually Does
MCP is infrastructure: the pipes that let an AI agent call external APIs, read external data, and take actions in external systems.
The specification defines how an AI host (the thing running the agent) communicates with MCP servers (the things that provide access to tools and data). When you ask an agent to check your calendar, the host issues an MCP call to a calendar server, which queries the actual calendar API and returns the result. The agent sees the result and incorporates it into its response.
The July 2026 revision removed protocol-level sessions, allowing each request to be handled independently. This simplifies server implementation but also changes the security model: there is less built-in context about who is asking and why. Each request has to carry its own authorization, and mistakes in that authorization propagate immediately.
MCP's design principles call for explicit user consent before data is exposed. Hosts are supposed to obtain permission before connecting to servers, and servers are supposed to respect scopes. These are principles, not enforcement: the spec describes what should happen, not what must happen at the protocol level. Implementation quality varies, and the incidents to date suggest it varies a lot.
The NSA's Warning
In June 2026, the NSA and CISA published joint guidance on MCP security. The document is aimed at organizations deploying MCP servers and the developers building them, but the concerns apply to anyone who uses AI agents that connect to their tools.
The guidance flags several risks. Open-source MCP agents have been observed exposing sensitive MCP server data, meaning the data your tools hold can be read by the agent and potentially forwarded elsewhere. Misconfigured authorization can allow cross-tenant access, where one customer's agent sees another customer's data. And prompt injection attacks can abuse tool access, tricking an agent into taking actions the user did not intend.
The recommendations are standard security practice, applied to a new domain: authenticate every request, scope permissions narrowly, log access, monitor for anomalies. The problem is that MCP adoption is outpacing security maturity. The pressure to ship integrations is immediate; the pressure to ship secure integrations is longer-term. The early incidents are the predictable result.
The Asana Incident
In June 2026, Asana disclosed that its MCP feature had caused cross-tenant data leakage. For roughly two weeks, an authorization flaw allowed data from one customer's Asana workspace to appear in responses to another customer's agent queries. Approximately one thousand organizations were affected.
The technical cause was a misconfiguration in how session context was handled across requests. The fix was straightforward once identified. The harder question is how it passed review in the first place, and the answer is probably speed: MCP integrations are a competitive feature, and the incentive to ship fast is strong.
A follow-up investigation found no evidence of exploitation. The exposure was real, but apparently no one noticed in time to abuse it. This is cold comfort. The same class of bug, in a more attractive target, with a longer detection time, would be a serious breach. The Asana incident is a warning shot, not a near miss.
| Risk | What happens | Example |
|---|---|---|
| Cross-tenant leakage | One user sees another's data | Asana, June 2026 |
| Over-permissioned scope | Agent can do more than intended | Calendar read becomes calendar write |
| Prompt injection abuse | Attacker tricks agent into action | Hidden instruction in a document |
| Logging exposure | Sensitive data in request logs | API keys in debugging output |
| Credential theft | Agent token captured and replayed | Session token in error message |
Why This Matters for Personal Knowledge
The incidents so far are enterprise-focused, but the same architecture is coming to personal tools.
When you give an agent access to your notes, your calendar, your task list, you are granting MCP access to your personal data. The agent can read what you wrote, see where you will be, know what you are working on. That is the point: it is why agents are useful. It is also why a misconfigured integration, or a compromised server, or a successful prompt injection, can reach further than a bug in a regular app.
The difference is scope. A bug in a note app affects the notes in that app. A bug in an MCP server that connects to multiple apps affects everything the server can reach. The more you connect, the larger the blast radius. And the pressure is always to connect more, because that is what makes the agent smarter.
This is not an argument against using agents. It is an argument for understanding what you are granting and limiting it deliberately. The default should be minimal access, expanded only when there is a clear reason, with the understanding that every connection is a surface.
How to Think About Agent Access
The useful frame is the same one that applies to any permission grant: what is the minimum access that gets the job done? If you want an agent to summarize your notes, it needs to read your notes. It does not need to write them, delete them, or share them. Grant read, not write. Scope to the folder, not the whole library.
The harder question is what happens when agents get more autonomous. Today you invoke an agent, it does a task, you see the result. Tomorrow an agent runs in the background, checks your tools periodically, takes actions on your behalf. The scope question becomes: what can it do while you are not looking? And the answer, if you are not careful, is everything you gave it access to.
The practical response is layered defense. Use MCP integrations from vendors you trust, because implementation quality matters and you cannot audit it yourself. Prefer read-only access where possible. Review what is connected periodically. And keep the things you really cannot afford to lose somewhere that is not connected to everything else, because the blast radius of a bug scales with what is reachable.
Mindly keeps your notes on your Mac, with AI that reads them locally rather than through a cloud protocol. The connection stays on your device. Local-first architecture →
What to Do Now
- Audit what is connected. If you use AI agents, check what MCP servers or integrations they have access to. Know what each one can read and write.
- Prefer read-only where possible. If an integration only needs to check your calendar, it does not need to modify it. Grant the minimum scope.
- Separate sensitive data. Keep the things you cannot afford to leak in a separate system, not connected to your agent's MCP universe.
- Watch for news of incidents. The Asana leak was disclosed; others may not be. Security researchers are paying attention to MCP now, and findings will surface.
- Ask vendors about their MCP security. If you use a tool that offers MCP integration, ask how they handle authorization, logging, and cross-tenant isolation. The answer tells you how seriously they take it.