Governed Cline in 3 minutes
Cline is the most-installed agent extension for VS Code — a planner-and-executor pair that edits files, runs commands, and calls external tools through the Model Context Protocol. Of the agent runtimes shipping today, Cline has the cleanest MCP-native architecture: tool calls don’t go through a custom hook surface, they go through MCP. That makes governance trivial — if you have somewhere to point MCP at.
This post is the 3-minute path: add Agentic Control Plane as a remote MCP server in Cline’s settings, and every external tool call Cline routes through MCP becomes audited, identity-attributed, and policy-checked. No code, no SDK — just JSON config.
The pattern
Cline’s MCP client speaks streamable-http natively. ACP exposes a streamable-http MCP endpoint at https://mcp.agenticcontrolplane.com/mcp. Authenticate with a gsk_ workspace key, and Cline routes its MCP-mediated tool calls through ACP’s governance pipeline before they fan out to whatever the tools actually do.
Three minutes from blank slate
1. Get an ACP key
cloud.agenticcontrolplane.com → create a workspace → Settings → API Keys → New key. Copy the gsk_yourslug_... value.
2. Open Cline’s MCP settings
In VS Code: sidebar → Cline icon → MCP Servers → Edit config.
3. Add ACP as a remote MCP server
{
"mcpServers": {
"acp": {
"url": "https://mcp.agenticcontrolplane.com/mcp",
"transport": "streamable-http",
"auth": {
"type": "bearer",
"token": "gsk_yourslug_replace-me"
}
}
}
}
Replace the token. Reload the VS Code window (Cmd+Shift+P → “Developer: Reload Window”).
4. Verify
Open cloud.agenticcontrolplane.com/activity. Ask Cline to do anything that hits an external tool routed through MCP. The call appears in the dashboard with client.name: "cline", the tool name, the input/output preview, and the policy decision — within seconds.
What you get for free
- Per-tool-call audit. Every MCP tool call Cline routes through ACP lands in the activity log with the tool name, input/output, latency, and decision.
- Policy enforcement. Set deny rules per tool, per tier, per identity. Cline sees a
tool_erroron denial and adapts. - PII / secret scanning. Output redaction on tool returns — Cline sees the redacted version, not the raw secret.
- Cross-framework audit. Cline tool calls sit alongside Claude Code, Cursor, Codex CLI, CrewAI, LangGraph, and any other framework wired into ACP. One log, one user identity, every agent your team runs.
What governance covers (and what it doesn’t)
Cline’s tool surface splits into two:
| Tool surface | Governed by ACP via this setup? |
|---|---|
| MCP-mediated external tools (GitHub, Salesforce, custom MCP servers) | ✓ Yes |
| Cline’s internal Composer tools (file edit, terminal, browser) | ✗ No |
Cline’s internal tools (file edit, run terminal, etc.) don’t go through MCP — they’re native to Cline’s architecture and don’t have an external interception surface today. Audit on those would require a hook seam Cline doesn’t expose. The MCP-mediated calls are where ACP fits.
For most production deployments that’s the right scope: the high-blast-radius calls (Salesforce writes, custom internal APIs, GitHub mutations) live in MCP servers, and that’s where the audit matters most. Local file edits and terminal runs in a developer’s VS Code session are a different threat model.
Token rotation
The gsk_ token sits in Cline’s MCP config as plain text. Use a workspace-scoped, rotatable key — not a long-lived admin key. Rotation is dashboard-side: revoke and reissue from the API Keys page; update Cline’s config file; reload the VS Code window.
Where this fits
The starter at acp-governance-sdks/examples/starters/cline is the runnable reference for the JSON config above. Every Cline-installed user on your team can drop the same block into their settings and inherit your workspace’s policy.
Cline integration guide → · What is an MCP Control Plane? → · Three-minute integrations → · Get started →