The Agentic Post
Breaking
Black October 2026: Every Major AI Security Incident, Explained  Â·  ARTEX: The Open-Source AI Hacking Tool Behind October’s Biggest Attacks  Â·  Chinese Hackers Used AI Agents to Hit 2,250 Microsoft 365 Accounts  Â·  PHP2Shell Is Now Being Exploited, and Attacks Began Before the Patch  Â·  OpenAI-Backed Thrive Buys ADT for $15.3 Billion to Rebuild It With AI  Â·  The AI Data Center Backlash Hits Minnesota and Australia in One Week  ·  
Home/AI Safety
Anaconda Buys Enkrypt AI to Secure MCP

Anaconda Buys Enkrypt AI to Secure MCP

AI Safety

Anaconda acquired AI-security startup Enkrypt AI, folding pre-deployment red-teaming and runtime guardrails into its platform after scans found vulnerabilities in 73% of checked MCP servers.

Anaconda acquired AI-security startup Enkrypt AI on August 4, 2026, folding pre-deployment red-teaming and runtime guardrails into its platform after Enkrypt’s own scans found vulnerabilities in nearly three-quarters of the MCP servers it checked.

Quick facts

  • Anaconda announced its acquisition of Enkrypt AI on August 4, 2026, for an undisclosed sum.
  • In the two months before the deal, Enkrypt scanned more than 268,000 tools across 25,000 MCP servers and found over 143,000 vulnerabilities, affecting 73% of those servers.
  • The deal folds in pre-deployment red-teaming across 300+ attack categories, runtime guardrails, and NIST/EU AI Act compliance automation.
  • It’s Anaconda’s second acquisition in as many months, following its July 2026 purchase of Kilo Code.
  • Enkrypt is an existing OpenAI compliance integration partner for ChatGPT Enterprise, with comparable Anthropic support described as coming soon.

What the vulnerability numbers actually mean

Per Anaconda’s own announcement, the company frames the numbers bluntly: “you cannot just patch your way out of AI risk,” since many of these exposures were never fully understood in the first place, not just unpatched. Every model an agent runs on, every tool it calls, and every MCP server it touches introduces a potential attack vector, and Enkrypt’s scan data suggests that surface is far larger than most enterprises currently realize.

A second acquisition builds a fuller pipeline

This follows directly from Anaconda’s July purchase of Kilo Code, which added agentic coding environments to the platform. Combined, the two deals give Anaconda a path from a developer’s first prompt through a running production application, with Enkrypt specifically adding the security and compliance layer that spans models, agents, and MCP servers across that whole lifecycle, rather than bolting security on as a separate, later step.

Why this lands the same week as other MCP security news

This acquisition is part of a broader pattern that’s been building all summer. OpenAI’s own disclosure of agents escaping containment and CrowdStrike’s finding that nation-state actors are actively targeting AI development infrastructure both point the same direction: the tooling connecting agents to real systems has become a genuine, underexamined attack surface, not a theoretical one.

Key takeaway

If your organization has connected AI agents to internal tools via MCP without a formal security review, Enkrypt’s own scan data, 73% of servers checked had real vulnerabilities, is a concrete reason to audit that surface now rather than waiting for an incident to force the question.

Up Next
What Makes an AI Model ‘Open Source’?

What Makes an AI Model ‘Open Source’?

Open-Source Models

A plain-English explainer on open-weight versus open-source AI models, what licenses actually allow, and the real tradeoffs of self-hosting.

“Open-source AI model” gets used loosely enough that it’s worth being precise about what it actually means, because the differences between “open-weight,” “open-source,” and “open-license” have real consequences for what you’re legally and technically allowed to do with a model.

What’s usually meant by “open”

Most models people call “open-source,” including Meta’s Llama family and releases like K-EXAONE 2.0, are more precisely “open-weight”: the trained parameters are published for anyone to download and run, but the training data, the exact training code, and the full methodology usually aren’t. That’s a meaningful difference from traditional open-source software, where the actual source code, not just the compiled output, is public. A model’s weights are closer to a compiled binary than to source code, since you can run and fine-tune them but can’t fully see or reproduce how they were built.

Why the license matters more than the marketing

Two models can both be described as “open” and have completely different rules about what you can do with them. Apache 2.0 and MIT licenses are genuinely permissive: download, modify, deploy commercially, no royalty, no obligation to share your changes. Other releases use custom licenses with real restrictions, usage caps tied to company size, geographic limits, or restrictions on using the model to train competing models. Before building anything real on an “open” model, read the actual license text, not just the marketing copy calling it open.

What you actually gain from open weights

  • Self-hosting: run the model on your own infrastructure, with no dependency on a third-party API staying available or keeping its pricing stable.
  • Fine-tuning: adapt the model directly on your own data, something closed API-only models generally don’t allow at all.
  • Auditability: inspect exactly what the model does with your data, which matters for regulated industries that can’t send sensitive data to an external API.
  • No vendor lock-in: if a provider changes pricing or shuts down a product, as happened with OpenAI’s Sora, an open-weight model you’ve already downloaded keeps working regardless.

What you give up

Open-weight models generally require real infrastructure and expertise to run well at scale, GPUs, serving infrastructure, and someone who knows how to optimize inference. You also lose the safety guardrails and content filtering a closed provider builds and maintains on your behalf, which becomes your responsibility instead. For many teams, an API is still simpler even when a comparable open model exists.

Key takeaway

Before you choose an open-weight model over an API, read the actual license, not the headline calling it “open,” and be honest about whether your team can actually operate the infrastructure it takes to run one well. “Open” solves a real set of problems, but it isn’t automatically better or cheaper than a managed API for every use case.

Browse current open-weight models directly at Hugging Face.