The Agentic Post
Breaking
AI and the Gig Economy  Â·  How to Choose an AI Vendor: A Checklist  Â·  USA TODAY Sues OpenAI for $250 Million Over 19 Newspapers  Â·  Zuckerberg Called Muse Ready Despite Safety Flags, NYT Reports  Â·  One Prompt Hijacked Every AWS AgentCore Agent in a Region  Â·  White House Makes AI Incident Reporting Mandatory After Anthropic Model Filed Visa Forms  ·  
Home/AI Agents/MCP & Protocols
MCP Security Best Practices

MCP Security Best Practices

MCP & Protocols

A practical guide to securing MCP connections, covering permission scoping, trusted sources, periodic audits, and safe authentication.

MCP’s rapid adoption has made it a real target, and Enkrypt AI’s own scan data, vulnerabilities in 73% of checked servers, makes a strong case that most teams haven’t applied basic security discipline yet.

The single most common vulnerability pattern is overly broad access granted by default and never revisited. An MCP server for reading calendar events shouldn’t also have write access to email, even if that’s technically convenient to set up once.

Prefer official, first-party servers published by the tool’s own maintainers over unofficial third-party implementations. An official server maintained by the people who understand the underlying API is a meaningfully lower-risk choice.

MCP connections accumulate quietly, the same way browser extensions do. Review what’s actually connected every few months, and remove anything you’re not actively using. Never authenticate by pasting credentials into chat, legitimate connections use the tool’s own login flow. Our step-by-step connection guide covers this in more detail.

Given how widespread real vulnerabilities have already been found, treating MCP connections with the same care as any other system access is worth the small extra effort. See Anaconda’s own findings on MCP vulnerabilities.

Up Next
1 in 5 Packages Your AI Suggests Do Not Exist

1 in 5 Packages Your AI Suggests Do Not Exist

AI Safety

Nearly one in five AI coding suggestions names a package that does not exist, and attackers are registering those exact names on npm and PyPI to harvest credentials at install time.

Nearly one in five package names suggested by AI coding assistants refers to software that does not exist, according to a 2026 study. Attackers have worked out which fake names models invent most often, registered them on npm and PyPI, and are waiting. The technique is called slopsquatting, and the payload typically harvests npm tokens, GitHub credentials and CI/CD secrets at install time.

Why do models invent package names at all?

Because they generate plausible text, not verified facts. A model does not check a registry in real time unless the surrounding toolchain gives it that ability. It produces a name that looks right based on naming patterns in its training data, and a hallucinated package name reads exactly as authoritative as a real one. This is the same underlying behaviour as any other hallucination, except the output is not a sentence you can sanity check. It is a command you run.

The crucial detail is that the fake names are not random. A model asked the same question repeatedly tends to invent the same name. That predictability is what makes the attack practical: observe the hallucination, register the name, wait.

How the attack actually runs

  • Attacker picks a trending library or plugin, because new things are not in training data and that is exactly when models start guessing
  • Asks an assistant to fetch it repeatedly, recording the fake name invented most often
  • Registers that name on npm, PyPI, GitHub or a plugin store
  • Hides the payload behind a raw URL, since most registry scanners do not follow those
  • Waits for a developer or an agent to install it, at which point install-time code runs

A variant called HalluSquatting applies the same idea to repositories and agent skills rather than packages. In January 2026, Aikido Security found a fabricated npm package, react-codeshift, that AI-written instructions were telling people to install.

Why agents make this much worse

A human developer might notice an unfamiliar package name and pause. An autonomous agent with permission to run install commands will not. The real failure is not model accuracy, it is that model output becomes an execution path with no verification step in between. Anyone whose assistant can fetch an outside resource and then run commands with little review is exposed.

This sits alongside two other agent-driven supply chain problems this year: the FakeGit campaign flooding GitHub with roughly 7,600 fake repositories posing as AI skills and MCP servers, and agents publishing 13,000 internal screenshots to public repos. Different mechanisms, same root cause: agents acting without a verification boundary.

What actually helps

Protect the install boundary, not the model. Verify that a package exists and has plausible history before installing. Disable install-time script execution where you can. Pin dependencies and use lockfiles. Require human approval before an agent installs anything new. And treat a package name from an assistant the way you would treat one from a stranger, because in the cases that matter, that is exactly what it is. The same reversibility principle applies: an install is not reversible once the script has run.

See The Hacker News on HalluSquatting.