DEV Community

Edison Flores
Edison Flores

Posted on

Cline just shipped Agent Plugins — here's why they need trust verification

#cline #mcp #aiagents #security

Cline just shipped Agent Plugins — here's why they need trust verification

Cline PR #13652 adds Hub-managed Agent Plugins — third-party plugins that auto-discover from ~/.agents/plugins and can contribute MCP servers, skills, and tools to the Cline runtime.

The security review by Cline's founder @saoudrizwan was thorough:

  • ✅ Auto-discovery is home-only (workspace plugins are ignored)
  • ✅ Path containment via realpath + symlink resolution
  • ✅ Remote MCP transports require HTTPS (unless loopback)
  • ✅ Plugin-configured headers are origin-bound
  • ✅ Header validation rejects userinfo/fragments

This is a solid baseline. But it's not enough.

What's missing: trust verification before execution

Cline's security model answers: "Is this plugin safe to load?"

It does NOT answer: "Is this plugin safe to execute?"

Once a plugin is loaded, its MCP server can:

  • Read any file the Cline process can access
  • Make network requests to any host
  • Spawn child processes
  • Access environment variables

The current model trusts the plugin after loading. There's no runtime verification.

What we built: @marketnow/trust-gateway 

npm install @marketnow/trust-gateway
Enter fullscreen mode Exit fullscreen mode

The gateway wraps any MCP server with a pre-exec filter that intercepts every tools/call BEFORE it reaches the server:

import { createPreExecFilter } from '@marketnow/trust-gateway';

const filter = createPreExecFilter({
  // Only allow these hosts
  allowHosts: ['api.github.com', 'registry.npmjs.org'],

  // Block these actions
  denyActions: ['shell_exec', 'rm_rf', 'DROP_TABLE'],

  // Log every call to a tamper-evident Merkle tree
  logSink: (event) => auditLog.append(event),
});

// Wrap your MCP server — Cline talks to the wrapper
const safeServer = filter.wrap(pluginServer);
Enter fullscreen mode Exit fullscreen mode

What it catches that Cline's model doesn't

We scanned 9,248 MCP servers. Here's what we found:

Threat Cline's model With trust-gateway
Plugin reads .env ❌ Not blocked ✅ Blocked
Plugin reads ~/.aws/credentials ❌ Not blocked ✅ Blocked
Plugin reads ~/.ssh/id_rsa ❌ Not blocked ✅ Blocked
Plugin spawns rm -rf / ❌ Not blocked ✅ Blocked
Plugin calls DROP TABLE ❌ Not blocked ✅ Blocked
Plugin contacts non-allowlisted host ❌ Not blocked ✅ Blocked
Plugin exfiltrates data via network ❌ Not blocked ✅ Logged + blocked

The full stack we shipped

This isn't just the gateway. We shipped the complete trust verification stack:

  • v5.1: Cryptographic Tool Fingerprinting (detect when plugin's tools change post-install)
  • v5.2: Behavioral Baseline + Drift Detection (detect when plugin behavior changes over time)
  • v5.3: Capability Graph + Org Policies (per-org risk context)
  • v5.4: Multi-Tool Attack Chain Detection (catch multi-step attacks across calls)
  • v6.0: Memory Poisoning Detection (detect injected instructions in plugin responses)

All open-source: https://github.com/alicelabs-llc/universal-trust-adapter

The ask

Cline's plugin model is the right architecture. The security baseline is solid. But runtime trust verification is the missing piece.

If you're building Cline plugins, wrap them with @marketnow/trust-gateway before loading:

npm install @marketnow/trust-gateway
Enter fullscreen mode Exit fullscreen mode

If you're the Cline team and want to discuss integrating trust verification into the plugin loading flow, I'm available. The gateway is 100% compatible — no Cline code changes needed.

— Edison Flores, AliceLabs LLC
https://www.marketnow.site · https://status.marketnow.site

Top comments (0)