A trending MCP install has 4,500 GitHub stars, no malicious code, no telemetry, a clean dependency tree and a real maintainer with a long history of reputable projects. It also happens to hand any malware on your machine full session-cookie access to your entire Google account, bypassing 2FA from any location in the world.
This isn't a supply-chain vulnerability. It's the auth model. And as the MCP ecosystem grows, this is the security question we are not asking loudly enough.
I went into this expecting to use the package, not review it. The plan was a small prototype involving NotebookLM and an agentic workflow. I read the install instructions before pasting them, which is how I ended up writing this instead.
What a package review covers
A package review on this MCP server would mostly produce green checks.
- No malicious code. No telemetry. No obfuscation. No post-install hooks.
- Real maintainer, seven years of GitHub history, multiple reputable projects.
- 4,500+ stars, dozens of watchers, meaningful community scrutiny.
- All dependencies mainstream.
- Outbound calls only to the service it integrates with.
None of that tells you what the binary, once running, can access on your behalf or what happens if its credential cache leaks. The interesting risks for MCP servers live at the integration boundary, not in the code itself.
Where the interesting questions are
Five questions worth asking of any MCP server before installing it.
- What credentials does it acquire and what is their scope? OAuth scoped to a single service is fundamentally different from full session cookies for an identity provider.
- Where are those credentials stored and with what protections? Plaintext JSON in a home directory is a different artifact than something held in the OS keyring.
- What is the blast radius if the credential store leaks? "Access to one notebook tool" is one thing. "Access to your entire Google account with 2FA already past" is another.
- What is the credential lifetime and how do you revoke? OAuth tokens rotate. Session cookies can live for weeks.
- What network surface does the MCP open while running? Local HTTP servers, debug ports, browser remote-debugging sockets.
The worked example
The specific case that prompted this piece is an MCP server for Google NotebookLM. NotebookLM has no public API. The maintainer is doing the only thing the constraint allows. He launches an isolated Chrome profile, has you log into Google inside it and scrapes the resulting session cookies into a local JSON file. File permissions are correct. Code is not malicious. The maintainer is doing reasonable work given the constraint.
The cookies, though, are not scoped to NotebookLM. They are full Google session credentials. Anyone who reads that file holds what your authentication produced: a logged-in session. They don't need to sign in, which means they don't need your password and they don't need to satisfy 2FA.
Whether the cookies work from the attacker's machine depends on Google's risk signals (device fingerprint, IP, behavior). Sometimes Google challenges, sometimes it doesn't. Used from your own device by another process running as you, the cookies just work, with no risk friction at all.
The instinctive defense is "but it's a local file, only I can read it". That defense is incomplete in the ways that matter.
- Any process running as the user can read it. A future malicious npm dependency, a compromised editor extension, a browser extension with file-system access.
- Cloud-backed backup paths (Time Machine, iCloud Desktop and Documents, Dropbox, OneDrive) will sweep it up without asking. That expands the blast radius to every machine the backup can be restored to.
- A lost or compromised laptop becomes remote account takeover, not just data loss.
This is not the maintainer's fault. It is structural. When a service does not offer scoped OAuth, the community fills the gap with browser-automation cookie scrapers. Those scrapers concentrate enormous credential authority into single small files. Multiply that by the rate at which the MCP ecosystem is now growing.
The tool surface, not just the auth model
There is a second structural problem worth naming. MCP servers register tools and the package README usually describes the headline use case. The full tool list is bigger.
The NotebookLM MCP exposes 39 tools. They include creating and deleting notebooks, ingesting arbitrary URLs and local files as new sources, sharing notebooks with collaborators and exporting contents to Google Docs and Sheets. Each one is a verb the LLM can choose to invoke.
Concretely, a prompt injection inside any document the LLM reads could attempt to share a private notebook publicly, export contents to a Doc the user does not own or ingest a malicious URL as a "source" that gets quoted back into future answers. Whether the user is bitten depends on the client's confirmation UX. The MCP server's own instructions say some tools have a confirm parameter, implying others do not.
The lesson: when adding an MCP server, audit the tool list, not just the package. The README tells you the headline. The tool list tells you what an attacker can actually do.
The pattern, not the package
This piece is not really about NotebookLM or about this specific package or about this specific maintainer. The maintainer is doing reasonable work. The pattern is what to pay attention to.
The MCP ecosystem is going to do to credential management what npm did to dependency management. The MCP ecosystem is going to do to credential management what npm did to dependency management. Fast growth, a broad mix of authors and a long tail of unofficial integrations filling gaps where vendors don't offer proper APIs. Some of them concentrate real credential authority in a small file most people will never audit. The security model that worked for npm dependencies (code review plus signature plus reputation) does not transfer cleanly. The artifacts that matter are no longer the packages themselves. They are the credential files those packages write to disk and the tool lists they expose to the LLM.
Enterprise security teams that wait for the npm-style supply chain attack model to apply to MCP will miss it entirely. The next class of incidents are not "a malicious MCP server was uploaded". It is "a benign MCP server's credential file was read by malware that arrived through a separate channel and the blast radius was someone's entire Google or Slack or GitHub identity".
The install commands take ten minutes. The threat model takes longer. Spend the time examining what you install.