DEV Community: Dan Barr

Introducing Virtual MCP Server: Unified Gateway for Multi-MCP Workflows

Dan Barr — Thu, 11 Dec 2025 15:59:12 +0000

If you're working with AI coding assistants like GitHub Copilot or Claude, you've probably encountered MCP (Model Context Protocol) servers. They're powerful, connecting your AI to GitHub, Jira, Slack, cloud providers, and more. But here's the problem: each connection requires separate configuration, authentication, and maintenance.

Managing MCP server connections gets messy fast. That’s why we built the Virtual MCP Server (vMCP) in ToolHive to solve this problem by aggregating multiple MCP servers into a single unified endpoint.

The problem: connection overload

Picture this: you're an engineer on a platform team. Your AI assistant needs access to GitHub for code, Jira for tickets, Slack for notifications, PagerDuty for incidents, Datadog for metrics, AWS for infrastructure, Confluence for docs, and your internal knowledge base. That's 8 separate MCP server connections, each exposing 10-20+ tools. Now your AI's context window is filling up with 80+ tool descriptions, burning tokens and degrading performance as the LLM struggles to select the right tools from an overwhelming list.

Each MCP server connection requires:

Individual configuration in your AI client
Separate authentication credentials
Manual coordination when tasks span multiple systems
Repeated parameter entry (same repo, same channel, same database)
Tool filtering to avoid context bloat and wasted tokens

Want to investigate a production incident? You're manually running commands across 4 different systems and piecing together the results yourself. Deploying an app? You're orchestrating a sequence of operations: merge PR, wait for CI, get approval, deploy, notify team. It's tedious, error-prone, and not reusable.

The solution: aggregate everything

vMCP transforms those 8 connections into one. You configure a single MCP endpoint that aggregates all your backend servers.

Before vMCP:

{
  "servers": {
    "github": { "url": "..." },
    "jira": { "url": "..." },
    "slack": { "url": "..." },
    "pagerduty": { "url": "..." },
    "datadog": { "url": "..." },
    "aws": { "url": "..." },
    "confluence": { "url": "..." },
    "docs": { "url": "..." }
  }
}

With vMCP:

{
  "servers": {
    "company-tools": {
      "url": "http://vmcp.company.com/mcp"
    }
  }
}

One connection. One authentication flow. All your tools available.

And here’s the key: you can run as many vMCP instances as you need. Your frontend team connects to one vMCP with their specific tools. Your platform team connects to another with infrastructure access. Each vMCP aggregates exactly the backends that each team needs, with appropriate security policies and permissions.

This matters for two reasons: security (no more giving everyone access to everything) and efficiency (fewer tools means smaller context windows, which means lower token costs and better AI performance).

What vMCP does

vMCP is part of the ToolHive Kubernetes Operator. It acts as an intelligent aggregation layer that sits between your AI client and your backend MCP servers.

1. Multi-server aggregation with tool filtering

All MCP tools appear through a single endpoint, but you cherry-pick exactly which tools to expose.

Example: An engineer on the ToolHive team gets a single vMCP connection with:

GitHub’s search_code tool (scoped to the stacklok/toolhive repo only)
The ToolHive docs MCP server
An internal docs server hooked up to Google Drive and filtered to ToolHive design docs
Slack (only the #toolhive-team channel)

No irrelevant tools cluttering the LLM's context. No wasted tokens on unused tool descriptions. Just the tools needed for their work, making it easier for the AI to select the right tool every time.

When multiple MCP servers have tools with the same name (both GitHub and Jira have create_issue), vMCP automatically prefixes them: github_create_issue and jira_create_issue. You can customize these names however you want.

2. Declarative multi-system workflows

Real tasks often require coordinating across multiple systems. vMCP lets you define deterministic workflows that execute in parallel with conditionals, error handling, and approval gates.

Example: Incident investigation

Instead of manually jumping between 4 different systems, copy/pasting data, and aggregating the results, a single “composite tool” could:

→ Query logs from logging system
→ Fetch metrics from monitoring platform  
→ Pull traces from tracing service
→ Check infrastructure status from cloud provider
→ Manually combine everything into a report
→ Create Jira ticket with findings

vMCP executes all queries in parallel, automatically aggregates the data, and creates the ticket. Define the workflow once, use it for every incident.

Example: App deployment

A typical deployment workflow handled end-to-end:

→ Merge pull request in GitHub
→ Wait for CI tests to pass
→ Request human approval (using MCP elicitation)
→ Deploy (only if approved)
→ Notify team in Slack

3. Pre-configured defaults and guardrails

Stop typing the same parameters repeatedly. Configure defaults once in vMCP.

Before: Every GitHub query requires specifying repo: stacklok/toolhive

After: The repo is pre-configured. Engineers never specify it, and they can't accidentally query the wrong one.

This isn’t just convenience, it’s about deterministic behavior and security. By pre-configuring parameters, you ensure tools behave consistently, and users can only access resources you’ve explicitly exposed. No more accidental queries to the wrong repo, Slack channels, databases, cloud regions, or anything else you reference repeatedly.

4. Tool customization and security policies

Third-party MCP servers often expose generic, unrestricted tools. vMCP lets you wrap and restrict them without modifying upstream servers.

Security policy enforcement: Restrict a website fetch tool to internal domains only (*.company.com), validate URLs before calling the backend, and provide clear error messages for violations.

Simplified interfaces: That AWS EC2 tool with 20+ parameters? Create a wrapper that only exposes the 3 parameters your frontend team actually needs, with safe defaults for everything else.

5. Centralized authentication

vMCP implements a two-boundary authentication model with a complete audit trail. Your AI client authenticates once to vMCP using the OAuth 2.1 methods defined in the official MCP spec. vMCP handles authorization to each backend independently based on its requirements.

When it’s time to revoke access, disable the user in your identity provider, and all backend access is revoked instantly.

Real-world benefits

Let's look at the incident investigation example with concrete numbers:

Without vMCP:

4 sequential manual commands
2-3 minutes per command
5-10 minutes aggregating and formatting
15-20 minutes total per incident
Results vary by engineer
Process isn't documented or reusable

With vMCP:

One command triggers the workflow
Parallel execution: 30 seconds
Automatic aggregation and formatting
Consistent results every time
Workflow is documented as code
Any team member can use it

For a team handling 20 incidents per week, that's 5-6 hours saved. More importantly, the response is faster, more consistent, and doesn't require senior engineers to handle routine investigations.

How it works

vMCP runs in Kubernetes alongside your backend MCP servers. You define three types of resources:

MCPGroup: Organizes backend servers logically (e.g., "platform-tools")

MCPServer: Individual backend MCP servers (GitHub, Jira, etc.)

VirtualMCPServer: The aggregation layer that combines servers from a group

The ToolHive operator discovers backends, resolves tool name conflicts, applies security policies, and exposes everything through a single endpoint. Your AI client connects to vMCP just like any other MCP server.

Since each VirtualMCPServer is a separate Kubernetes resource, you can deploy as many as needed. One per team, one per environment, or organized however makes sense for your security model.

For a working example, check out the quickstart tutorial.

When to use vMCP

vMCP makes sense when you're managing multiple MCP servers (typically 5+), curating a subset of MCP tools for specific teams and workflows, or need tasks that coordinate across systems. It's especially valuable for:

Teams requiring centralized authentication and authorization
Workflows that should be reusable across the entire team
Security policies that need centralized enforcement
Reducing onboarding complexity for new engineers

If you're using a single MCP server for simple one-step operations, you probably don't need vMCP. It's built for managing complexity at scale.

Get started

vMCP is available now as part of ToolHive. To try it out:

Install the ToolHive Kubernetes Operator
Follow the vMCP quickstart
Connect your AI client to the aggregated endpoint

We'd love to hear how you're using vMCP. What workflows are you building? Which MCP servers are you aggregating? Join the ToolHive community on Discord and let us know.

Looking to leverage vMCP within your enterprise organization? Book a demo with us.

ToolHive is an open-source MCP platform focused on security and enterprise operationalization. Learn more at toolhive.dev.

Cut token waste from your AI workflow with the ToolHive MCP Optimizer

Dan Barr — Tue, 28 Oct 2025 17:12:08 +0000

If you’ve ever hit a rate limit in your AI assistant or felt the sting of regret after checking your usage bill, you’re not alone. Whether you’re exploring an open source repo or triaging issues for a sprint, running into token walls is disruptive. It breaks your flow and burns your time and money.

Turns out, there’s a hidden cost in many of today’s AI-enhanced dev workflows: tool metadata bloat. When dozens (or hundreds) of tools get injected into each prompt, it drives up token usage and slows down responses. Input tokens aren’t free, and cluttering the context window with irrelevant content degrades model performance.

At Stacklok, we’ve been working with the Model Context Protocol (MCP) and discovered something surprising. A significant chunk of the tokens burned during AI coding sessions doesn’t come from your prompt, or even the code. It comes from tool descriptions.

MCP Optimizer, now available in ToolHive, tackles this problem at the root. It reduces token waste by acting as a smart broker between your AI assistant and MCP servers.

Where the waste comes from

Let’s say you’ve installed MCP servers for GitHub, Grafana, and Notion. You ask your assistant:

“List the 10 most recent issues from my GitHub repo.”

That simple prompt uses 102,000 tokens (total input & output), not because the task is complex, but because the model receives metadata for 114 tools, most of which have nothing to do with the request.

Other common prompts create similar waste:

“Summarize my meeting notes from October 19, 2025”
uses 240,600 tokens, again with 114 tools injected, even though only the Notion server is relevant
“Search dashboards related to RDS”
consumes 93,600 tokens

In each case, only a small fraction of those tokens are relevant to the task. Even saying “hello” burns more than 46,000 tokens.

Multiply that across even a few dozen prompts per day, and you’re burning millions of tokens on context the model doesn’t need. That’s not just expensive, it’s disruptive. In rate-limited enterprise environments or time-sensitive projects, this inefficiency slows down responses, breaks flow, and cuts directly into productivity.

Introducing MCP Optimizer: Smarter tool selection for leaner prompts

Instead of flooding the model with all available tools, MCP Optimizer introduces two lightweight primitives:

find_tool: Searches for the most relevant tools using hybrid semantic + keyword search
call_tool: Routes the selected tool request to the appropriate MCP server

Here’s how it works:

You send a prompt that requires tool assistance (for example, interacting with a GitHub repo)
The assistant calls find_tool
MCP Optimizer returns the most relevant tools (up to 8 by default, but this is configurable)
Only those tools are included in the context
The assistant uses call_tool to execute the task

The results are dramatic. Using the GitHub, Grafana, and Notion MCP servers from the example above:

Prompt	MCP server used	Without MCP Optimizer	With MCP Optimizer	Token reduction
Hello	None	Tokens*: 46.8k Tools sent: 114	Tokens: 11.2k Tools sent: 3	76%
List the latest 10 issues from the stacklok/toolhive repository.	GitHub	Tokens: 102k Tools sent: 114	Tokens: 32.4k Tools sent: 11	68%
Summarize my meeting notes from Oct 19th 2025	Notion	Tokens: 240.6k Tools sent: 114	Tokens: 86.8k Tools sent: 11	64%
Search the dashboards related to "RDS" in my Grafana workspace	Grafana	Tokens: 93.6k Tools sent: 114	Tokens: 13.7k Tools sent: 11	85%

* Total input & output tokens for the request

By sending only what’s needed, MCP Optimizer reduces total token usage, shortens response times, and prevents the assistant from thrashing through irrelevant tools.

No tokens wasted on excessive metadata. No LLMs spiraling as they try to reason through 100+ tools. Just fast, efficient execution.

Try it now

MCP Optimizer is available today as an experimental feature in the ToolHive desktop app. Here’s how to get started:

Download ToolHive for your platform.
Follow the Quickstart guide and MCP usage guides to install a few MCP servers into the default group (or another group of your choice).
In the Settings (⚙️) screen, enable MCP Optimizer under Experimental Features.
On the MCP Servers screen, click MCP Optimizer, and enable optimization for the default group.
Open the default group and click Manage Clients to connect your favorite AI client.
The optimizer discovers the MCP servers and tools in the default group, and ToolHive automatically connects your clients to the optimizer MCP server.
In your AI client, send prompts that require tool usage, like: “Find a good first issue in the stacklok/toolhive repo to start working on.”

For more, see the full tutorial in the ToolHive documentation.

What’s next

We’re building ToolHive and MCP Optimizer in the open, and your feedback helps shape what comes next.

Explore the project at toolhive.dev and join our community on Discord to share your experiences, suggest features, and help make tool-driven AI workflows faster, safer, and more developer-friendly.

Examining the impact of npm supply chain attacks on MCP

Dan Barr — Thu, 18 Sep 2025 15:03:39 +0000

Last week, a significant supply chain attack hit the JavaScript/TypeScript ecosystem through the npm registry. Multiple widely used packages, collectively downloaded more than 2 billion times per week, were compromised via a single maintainer’s npm account.

Malicious versions of debug, chalk, ansi-styles, and 15 other packages were published. The payload focused on stealing cryptocurrency wallets, but the incident underscored a broader, ongoing risk: the open source supply chain is a high-value target.

And it didn’t stop there. This week, another campaign dubbed "Shai-Hulud" targeted additional npm packages, this time exfiltrating sensitive data and attempting self-propagation across the ecosystem.

Plenty has already been written about these attacks. Here, I’ll focus on the impact on the Model Context Protocol (MCP) ecosystem. A quick scan of npm-based MCP servers showed that a significant percentage were at risk.

Why were so many MCP servers exposed?

The compromised packages are foundational in the JavaScript/TypeScript ecosystem. For MCP specifically, they are indirect dependencies of the official MCP TypeScript SDK. Any MCP server built from the SDK was therefore potentially vulnerable.

Most JS/TS MCP servers are run by clients with npx, which executes arbitrary commands from npm packages. During execution, all direct and transitive dependencies are pulled down to the local system. Unless wrapped in a Docker container, the server inherits the same access you have to your machine, networks, and data.

What should MCP users do?

Fortunately, the malicious versions were quickly identified and removed, limiting downstream damage. But assume the worst and take proactive steps:

Check and update the versions of MCP packages you use.
Clean your npm/npx cache (npm cache clean --force) and restart your MCP clients.
Pin package versions instead of defaulting to @latest.

Looking forward, apply the same discipline you would for any code you run locally:

Keep MCP servers up to date.
Prefer servers that are actively maintained.
Favor containerized MCP servers to limit their blast radius.

What should MCP server maintainers do?

If you maintain an npm MCP server, rebuild and publish a fresh version, even if you don’t think you were affected. The cost is low, and it eliminates the chance that a malicious dependency slipped in during the attack window.

Longer term, there are best practices every maintainer should follow:

Audit dependencies regularly with npm audit or similar tools.
Automate updates of direct and indirect dependencies with tools like Dependabot.
Pin direct dependency versions.
- Be cautious: these attackers used patch releases, so even a narrow version range like ~1.2.3 would have matched.
Check your lock file into version control so builds are reproducible.
Offer containerized builds of your MCP server.

ToolHive: a secure approach to MCP

At Stacklok, we’re working to secure MCP servers via our open source project, ToolHive.

We’ve made deliberate choices in the design and development of ToolHive with security in mind. For example, one of our earliest architectural decisions was to require containerization for MCP servers.

We re-package a curated set of MCP servers as container images in the ToolHive registry. When we learned about this attack, we proactively rebuilt these images as soon as the malicious packages were removed from the npm registry. For third-party images in our registry, we use strict version pinning, ensuring users didn’t pull potentially vulnerable releases during the attack window.

Containerization brings runtime consistency and portability, but more importantly, it limits exposure: a compromised MCP server is isolated from the rest of your system.

ToolHive goes further by including network isolation. You can restrict outbound access so MCP servers only connect where they need to. Safe defaults are built into the registry. For example, the GitHub MCP server can be protected with a single CLI flag or UI toggle:

thv run --isolate-network github

Conclusion

The npm supply chain attack of September 8, 2025 reached deep into the MCP ecosystem. The actual impact depended on how servers were developed and deployed. Container isolation, and especially when combined with network isolation, proved to be an effective defense.

This isn’t about a single tool. It’s a reminder that security has to be baked into how we develop and run software. Supply chain attacks will continue to evolve. Our practices must evolve faster.

How to secure MCP servers with Vault + ToolHive in Kubernetes

Dan Barr — Wed, 17 Sep 2025 18:31:48 +0000

Running MCP servers in Kubernetes often means dealing with the headache of managing secrets. Hardcoding them? Too risky. Mounting them directly? Too messy.

That’s where ToolHive’s Vault integration tutorial comes in. It shows you how to use HashiCorp Vault to provide secure, controlled access to secrets for MCP servers, without exposing more than you should.

We also put together a short video demo to walk you through it:

If you’re running Kubernetes and want to simplify how your MCP servers access secrets, ToolHive and Vault help you get there faster.

Who are your MCP servers talking to?

Dan Barr — Thu, 26 Jun 2025 15:25:58 +0000

You probably know who you think they should be talking to, but how do you know for sure? And how do you keep it that way?

Modern AI workflows rely on agentic systems that leverage Model Context Protocol (MCP) servers. These servers provide rich context to LLMs, enabling smarter, safer, and more customized behavior. But if you’re not controlling their network access, you’re trusting that these tools won’t spill secrets, phone home, or tunnel into places they shouldn’t.

With the new network isolation features in ToolHive, you don’t have to trust. You can verify – and enforce.

Let’s prove the point with a quick test.

I gave the Fetch MCP server a very strict permission profile: it could only connect to stacklok.com and nothing else. Then I used Copilot to fetch content from both stacklok.com and anthropic.com.

Here’s what happened:

And the audit trail from the egress proxy that ToolHive spun up for me:

$ docker logs fetch-egress

1750875295.189    449 172.20.0.4 TCP_TUNNEL/200 10451 CONNECT stacklok.com:443 - HIER_DIRECT/5.161.48.178 -
1750875314.012      0 172.20.0.4 TCP_DENIED/403 3786 CONNECT www.anthropic.com:443 - HIER_NONE/- text/html

✅ Allowed: stacklok.com

⛔ Blocked: anthropic.com

That’s real-time enforcement of network policy, with a full audit trail. No special infrastructure required.

Let’s look at why this matters, and how you can do it yourself.

Why network isolation matters

Containerization is a great start for security, but it’s not a silver bullet. A malicious MCP server could still:

Exfiltrate proprietary data or credentials
Leak sensitive API access to an unknown endpoint
Become a pivot point for lateral movement within your network

The attack surface expands when containers are able to download unverified tools, or when a once-trusted MCP gets silently updated with malicious code. These aren’t theoretical risks, they’ve already shown up in detailed proof of concept research. Even legitimate MCP servers can be manipulated to devious ends through prompt injection and other techniques, like this exploitation of the WhatsApp MCP.

That’s why ToolHive lets you explicitly define where each MCP can connect, and just as importantly, where it can’t.

How to lock it down

ToolHive’s permission profiles let you precisely define network rules for each MCP server. Here’s a quick walkthrough of some common use cases.

Example 1: Allow only internal domains

Suppose you want to restrict the Fetch MCP server to only talk to your local system, internal corporate services, and your tenant in Atlassian Cloud:

fetch-permissions.json

{
  "network": {
    "outbound": {
      "allow_host": [
        "localhost",
        ".acmecorp.com",
        "acmecorp.atlassian.net"
      ],
      "allow_port": [80, 443],
      "insecure_allow_all": false
    }
  }
}

Note the syntax of the .acmecorp.com entry. The leading . permits all subdomains below the main domain.

Then, simply launch the Fetch server with the --isolate-network flag and your custom permission profile:

thv run --isolate-network --permission-profile ./fetch-permissions.json fetch

Example 2: Use default registry permissions

Some MCPs ship with default profiles in the built-in ToolHive registry. Want to run the GitHub MCP as-is?

thv run --isolate-network github

You can inspect its default permissions first:

thv registry info github

The Permissions section reveals the default policy:

Permissions:
  Network:
    Allow Host: .github.com, .githubusercontent.com
    Allow Port: 443

Example 3: Customize for GitHub Enterprise

If you self-host GitHub, tweak the permission profile to replace the allow_host list with your internal name:

{
  "network": {
    "outbound": {
      "allow_host": ["github.example.com"],
      "allow_port": [443],
      "insecure_allow_all": false
    }
  }
}

And run with your custom profile:

thv run --isolate-network --permission-profile ./github-enterprise.json github

Example 4: Block all network access

Need to sandbox an MCP completely? Use the built-in "none" profile:

thv run --isolate-network --permission-profile none <MCP_SERVER>

How it works

Behind the scenes, ToolHive runs each MCP server inside a locked-down container within that routes egress traffic through a layer 7 HTTP proxy. That proxy enforces the rules you define in your permission profile.

You can:

Block access entirely
Allow specific domains, IPs, and ports
Monitor attempted connections using logs

It’s simple to apply and doesn’t require you to manage iptables, Squid rules, write sidecar policies, or wrangle your own container network routing.

Pro tips

Don’t know what to allow? Start with --permission-profile none and check the logs for denied requests.

  docker logs <mcp-name>-egress

Need auditability more than isolation? Set "insecure_allow_all": true in your profile and run with --isolate-network to log everything without blocking. Currently, the proxy logs are ephemeral inside the egress container, but if you’d like to see a persistence option please let us know via a GitHub issue!

Safer defaults, smarter agents

As AI tooling becomes more agentic — running background tasks, accessing services, and making autonomous decisions — you’ll need guardrails that match the autonomy. Network isolation is one of the simplest, most powerful controls you can put in place.

Ready to take control of your MCP network surface?

🚀 Follow the quickstart guide to get up and running fast
📄 Learn more about network isolation in the custom permissions guide
⭐ Check out ToolHive on GitHub to explore the code and contribute
💬 Join the Stacklok Discord to get support, ask questions, or share your feedback

Build smarter, safer AI workflows, one locked-down container at a time.

Easy and secure MCP servers, now on Windows

Dan Barr — Thu, 05 Jun 2025 15:00:00 +0000

ToolHive v0.0.39 is here, and it comes with a big update for developers: native Windows support!

Previously, ToolHive worked great on macOS and Linux. But if you develop on Windows, your only option was WSL. That got the job done, but it came with limitations, especially around client auto-configuration. Now with native support, you get the full experience, including seamless integration with VS Code, Cursor, and other supported tools.

What is ToolHive?

ToolHive makes it easy and secure to run Model Context Protocol (MCP) servers. It wraps any MCP server in a lightweight, locked-down container, taking care of orchestration, security, and client configuration so you can focus on building.

With ToolHive, you can:

Easily discover high-quality MCP servers through the built-in registry
Spin up an MCP server with a single thv run command using Docker or Podman under the hood
Securely pass secrets and mount volumes
Automatically configure clients like GitHub Copilot in VS Code, Cursor, Cline, and more

ToolHive isn't just for individual developer workstations, it's also designed with long-term scale and security in mind. Features like Kubernetes integration and support for OAuth-based client auth lay the groundwork for more robust, team-ready deployments.

What’s new in v0.0.39 and why it matters

With this release, ToolHive offers:

First-class support for native Windows environments. You now have access to the full ToolHive experience. That includes the automatic configuration of clients, one of the major reasons developers love ToolHive. No more digging through docs or .json settings to wire things up manually.
Full client auto-discovery and integration on Windows for supported tools. Auto-discovery means ToolHive can automatically register new MCP servers with your tools as soon as they start. This was previously only possible on macOS and Linux, but no longer!

This release also underscores a broader commitment: ToolHive should feel like it belongs on your platform, whether you’re using it for a single MCP server or managing a fleet across a team.

How to install it

The only prerequisite is to have Docker Desktop or Podman Desktop installed and running on your system. To install the ToolHive CLI, you’ve got three options:

1. Use WinGet

WinGet is built into all current versions of Windows 10 and 11 and is the easiest way to install ToolHive. Just run:

winget install stacklok.thv

2. Download the prebuilt `.exe`

Head over to the ToolHive GitHub releases page and grab the latest Windows binary. Extract the ZIP, move it somewhere in your PATH, and you’re ready to go.

3. Build from source

Have Go 1.24 installed? Then you can build ToolHive yourself:

git clone https://github.com/stacklok/toolhive.git
cd toolhive

go install .\cmd\thv

Ready to get started?

Check out the ToolHive repo
Join the Stacklok Discord to ask questions or share feedback

We’re always looking to make ToolHive more powerful, more secure, and more developer-friendly. This release is one small step for cross-platform support, one giant leap for better context-aware development. 🚀

Rewriting an old app with AI: a reality check

Dan Barr — Fri, 28 Mar 2025 17:05:37 +0000

TL;DR:

AI coding tools and the LLMs that drive them can be powerful, but they’re not security-aware by default.
Outdated packages and insecure practices can creep in. Don’t assume LLMs "just know."
Clear, specific prompts matter more than you think.
Don’t skip automated linters, SAST/DAST tools, or dependency checkers. AI doesn’t replace them.
Code review still matters. A lot.

Throughout my career, I’ve brought a healthy skepticism to the hype that comes with each new wave of technology, and AI code generation is no different. Even now, working at a company building tools to improve security and productivity for AI-assisted developers, I’ve had my doubts. Can LLMs actually produce high-quality, secure code? Can they be trusted with real-world applications, especially for people like me who aren't full-time developers?

That skepticism shapes how I've approached my exploration of these tools. I’m not just curious about what they can do out of the box, I want to understand how to use them effectively. Where do AI coding assistants and LLMs genuinely help? Where do they fall short? And how can we guide them to get better results?

It quickly became clear that AI can help write code but doesn’t take on responsibility for it. That still falls on us, especially when it comes to keeping things secure. LLMs don’t “just get it.” You're still responsible for ensuring the code you deploy is secure, even if an AI writes it. "Vibe coding" with an AI won’t save you when it generates an insecure login page or uses deprecated packages.

A real-world experiment

For context: I have a computer science degree and spent time as a developer early in my career. I quickly pivoted into infrastructure, where I focused heavily on automation, and now work in technical marketing with a recent focus on AI assisted coding. I’ve kept my foundational understanding of app structure and security risks, but I relied on AI tools here both to teach myself how to work with them and to fill in the gaps in my Python knowledge.

I recently dusted off a very old PHP-based web app. It’s a small tool for checking in attendees at community meetups, printing name badges, and picking winners for door prizes. Not mission-critical by any means, but I was curious how an LLM like Claude could help modernize it.

So I used Cline and asked Claude 3.7 Sonnet to rebuild it in Python/Django. A few prompts and iterations later, I had a working app. Victory, right?

Not quite.

The problems

Old versions: Claude defaulted to Django 4, even though Django 5 was released well before its knowledge cutoff. Claude probably made this choice because most public examples during its training were still based on Django 4. LLMs generate code based on what they’ve seen most often, not necessarily what’s most current. I had to explicitly ask for Django 5 before it even considered using it.
Outdated dependencies: Most of the libraries it picked were outdated (by years in some cases) even within the model’s supposed knowledge window.
Password security fail: For the admin login, Claude implemented MD5 hashing for password storage. In 2025. Yikes.
OWASP Top 10? Nope: When I asked it to review its own code against the OWASP Top 10, it found glaring issues: insecure cookies, XSS risks, poor session handling.

These weren’t edge cases or niche scenarios. They were textbook mistakes.

What I took away

This experience clarified a few things for me:

Prompt engineering really matters. If I had started by specifying what versions to use, which tools to integrate, and what security standards to follow, I would have gotten better results. Instead, I gave a casual, open-ended prompt and got casual, open-ended code in return.
Security tooling is essential. Arguably even more so with AI-assisted workflows. Using an LLM to generate code doesn't reduce the need for linters, scanners, or security checks; it makes them more critical. Tools like pylint, bandit, and trivy help with dependency and security scanning. Guidance from resources like the OWASP Top 10 rounds out the picture. These aren’t optional, they're lifelines.
Code review is still critical. Just because it compiles and works doesn’t mean it’s good. Experience helps you see what automated tools (including LLMs) don’t.

A checklist for safer AI coding

If you’re using AI to help write or refactor apps:

Be specific: Name your preferred versions, frameworks, and security practices in the prompt.
Break it into smaller pieces: For migration projects, split the codebase into manageable units (DB, business logic, API, etc.) and prompt the AI layer-by-layer. This reduces context overload and makes review easier.
Automate review: Use linters, SAST/DAST tools, and SBOM scanners in your CI/CD pipeline. Don’t ship without them.
Don’t skip human review: Nothing replaces experienced eyes on code.

Final thought

AI-assisted development is powerful, but it’s not magic. It still requires thoughtfulness, review, and good security hygiene. LLMs can save time writing and reviewing code, but that time savings can quickly disappear if you’re cleaning up after a security incident. A little extra effort up front is still the best defense against costly surprises later.

If you've tried AI coding tools, what surprises or pitfalls have you run into? Let me know in the comments.

Augment Cline and your LLM with up-to-date risk insight using CodeGate

Dan Barr — Thu, 30 Jan 2025 16:25:04 +0000

The CodeGate team has landed another integration! 🚀 We're thrilled to announce that CodeGate now supports Cline, the popular autonomous coding assistant for VS Code!

Consider this: what happens when Cline communicates with an LLM that hasn't been updated in months? It might suggest using outdated libraries or ignore potential security threats lurking in new dependencies. And since Cline works with your entire codebase and human error is inevitable, a slip-up could expose sensitive information like API keys and put your projects at risk.

Enter CodeGate, the perfect complement to Cline's agentic workflow and autonomous coding abilities. By integrating CodeGate with Cline, you're adding an extra layer of protection to your development process. CodeGate keeps your secrets local so that sensitive information like API keys remain secure within your environment. It also examines dependencies for potential risks, using its up-to-date knowledge to warn you about malicious packages or outdated libraries, and guides the LLM to safer alternatives.

CodeGate is a free and open source gateway, shipped as a single Docker container, that works behind the scenes to analyze every interaction between Cline and your LLM. CodeGate has your back, so you can let Cline manage your coding tasks with confidence.

Check out the demo to see how it works.

Learn more about CodeGate on GitHub, check out the docs to get started, and join us on Discord!

Give aider a privacy and security boost with CodeGate

Dan Barr — Fri, 24 Jan 2025 18:16:21 +0000

We know you love aider...how it works right from your terminal, understands your codebase, and its automated Git commits.

But what happens when aider talks to an LLM that was trained many months ago and doesn't know about the latest risky dependencies and malicious packages? Or when you accidentally let an API key slip into your code and it gets shared with OpenAI?

Now, you can pair aider with CodeGate to give your favorite AI pair programmer a privacy and security boost! Using CodeGate with aider keeps your secrets local, your dependencies secure, and your projects safe from vulnerabilities.

Check it out in this demo video:

Aider + CodeGate: better together!

Learn more about CodeGate on the website, check out the docs to get started, and join us on Discord!

Avoid risky dependencies in AI generated code

Dan Barr — Wed, 22 Jan 2025 22:37:29 +0000

The LLMs that power your favorite AI coding assistants like GitHub Copilot or Continue take a lot of time and money to train, so they're not working with up-to-date knowledge. In fact, their knowledge cutoff dates are often 12-18 months in the past.

That means they don't know anything about the latest threats in the open source package ecosystem, like malicious packages. They also don't know which projects have been deprecated or archived since they were trained.

CodeGate augments your LLM's knowledge with an up-to-date database of risky packages in five popular ecosystems (PyPI, npm, golang.org, crates.io, and Maven), powered by Stacklok Insight. CodeGate is a new open source project from Stacklok that runs locally to protect your privacy and security while you use AI coding tools.

In this video, see how CodeGate automatically protects you from malicious or deprecated dependencies without changing how you work with your AI coding assistant.

Learn more about CodeGate on the website, check out the docs to get started, and join us on Discord!

Stop AI coding assistants from leaking your secrets

Dan Barr — Thu, 16 Jan 2025 16:28:57 +0000

You're careful not to let your secrets wind up in source code. You use .gitignore files. You scan for secrets with TruffleHog and turn on GitHub's push protection. But despite all this, chances are your AI coding assistant is sharing your secrets with a large language model (LLM) in the cloud. 😱

That's where CodeGate comes in. CodeGate is a new open source project from Stacklok that runs locally to protect your privacy and security as you use AI coding tools.

In this feature spotlight video, I show you how CodeGate encrypts your secrets before they are sent to an LLM, without changing how you interact with your AI coding assistant.

Learn more about CodeGate on the website, check out the docs to get started, and join us on Discord!

Your dependencies have dependencies: new features to assess risk

Dan Barr — Tue, 12 Nov 2024 21:12:50 +0000

Stacklok has just rolled out some major updates to Trusty, our free-to-use service that helps developers assess dependency risk in open source packages. These new features are designed to help you make informed decisions about the software dependencies you bring into your projects.

Transitive dependency analysis

The open source ecosystem is a complex web of interdependencies and relationships. When you’re picking the right packages to use in your project, assessing them for risk is a great way to make your project more secure. But the first layer of dependencies only scratches the surface. Your dependencies have dependencies, and so do those, and so on -- it's ~~turtles~~ dependencies all the way down. Those indirect dependencies further down the tree might bring hidden vulnerabilities or license compliance risks that aren't immediately obvious.

Trusty now ingests and analyzes transitive dependencies to help you understand the full scope of your dependency tree. For each package version, Trusty crawls the dependency tree to identify the package's direct and indirect dependencies. Along with the list of downstream packages, Trusty surfaces key risk indicators, license information, and activity scores to help you understand the full scope of potential security and health risks lurking deep within your dependency chain.

Refreshed UI and security signals

The Trusty web interface has a fresh new look, highlighting more intuitive security signals and activity scores. Our goal is to make it easier to quickly assess health and security signals and to help you make a decision based on the risk and activity signals that matter most to you.

And for those who prefer to walk on the dark side, Trusty now fully supports dark mode. 😎

Check out an overview of the new UI in the docs: https://docs.stacklok.com/trusty/how-to/package-overview/

New API version

Of course, the best way to use Trusty is to integrate it directly into your development flow. Version 2 of the Trusty API is now available with new and updated endpoints supporting the latest scoring updates and features like transitive dependencies. You can check out the new and improved API docs here: https://docs.stacklok.com/trusty/ref/api/

The quickest way to get started with automating Trusty is the integration with Minder, the open-source software supply chain automation tool that Stacklok recently donated to the OpenSSF. And check out Stacklok Cloud, our fully managed public SaaS instance of Minder that is free to use with public repositories.

Let us know what you think

At Stacklok, we’re committed to helping all developers navigate the complex world of open source dependencies and build more secure software. Check out Trusty today at https://trustypkg.dev to start understanding your software supply chain risk.

As always, we're eager to hear your feedback. Leave a comment below, and join us in the Stacklok community Discord to chat about the updates, package scoring, and software supply chain in general!

DEV Community: Dan Barr

Introducing Virtual MCP Server: Unified Gateway for Multi-MCP Workflows

The problem: connection overload

The solution: aggregate everything

What vMCP does

1. Multi-server aggregation with tool filtering

2. Declarative multi-system workflows

3. Pre-configured defaults and guardrails

4. Tool customization and security policies

5. Centralized authentication

Real-world benefits

How it works

When to use vMCP

Get started

Cut token waste from your AI workflow with the ToolHive MCP Optimizer

Where the waste comes from

Introducing MCP Optimizer: Smarter tool selection for leaner prompts

Try it now

What’s next

Examining the impact of npm supply chain attacks on MCP

Why were so many MCP servers exposed?

What should MCP users do?

What should MCP server maintainers do?

ToolHive: a secure approach to MCP

Conclusion

How to secure MCP servers with Vault + ToolHive in Kubernetes

Who are your MCP servers talking to?

Why network isolation matters

How to lock it down

Example 1: Allow only internal domains

Example 2: Use default registry permissions

Example 3: Customize for GitHub Enterprise

Example 4: Block all network access

How it works

Pro tips

Safer defaults, smarter agents

Easy and secure MCP servers, now on Windows

What is ToolHive?

What’s new in v0.0.39 and why it matters

How to install it

1. Use WinGet

2. Download the prebuilt .exe

3. Build from source

Ready to get started?

Rewriting an old app with AI: a reality check

TL;DR:

A real-world experiment

The problems

What I took away

A checklist for safer AI coding

Final thought

Augment Cline and your LLM with up-to-date risk insight using CodeGate

Give aider a privacy and security boost with CodeGate

Avoid risky dependencies in AI generated code

Stop AI coding assistants from leaking your secrets

Your dependencies have dependencies: new features to assess risk

Transitive dependency analysis

Refreshed UI and security signals

New API version

Let us know what you think

2. Download the prebuilt `.exe`