HOW TO SECURE CLINE

Cline Security Context

Cline is an open-source autonomous agent that runs as a VS Code extension. It can read and edit files, execute terminal commands, and (with the browser tool) load web pages — all under the LLM provider you supply (Anthropic, OpenAI, Bedrock, OpenRouter, etc.). Two distinct attack surfaces: the agent’s actions on your machine (controlled by approval mode and .clineignore), and the AI-generated code it produces (same default-insecure patterns as every other code-gen tool). The browser tool is the additional surface unique to Cline — every page Cline loads can attempt prompt injection.

What You’ll Learn

• How to configure approval mode so Cline can’t run commands without your OK
• API key security across multiple LLM providers
• Why browser access is a prompt-injection vector and how to scope it
• Directory restrictions and .clineignore setup

Critical Steps

1. Configure your LLM provider’s API key safely

Cline asks for an API key per provider. Store via the VS Code Secret Storage (the default), not in .vscode/settings.json (which can be committed). For team setups, use a provider that supports per-user keys with usage caps — a leaked key with no cap is a five-figure bill within hours.

2. Disable auto-approve for file modifications

In Cline → Settings → Auto-approve: leave “Edit files” off until you trust the project. Auto-approving edits means Cline can rewrite any file in the workspace without prompting — including package.json, .gitignore, or your CI config. The right starting point is “approve every edit”; relax later for repeat workflows.

3. Disable auto-approve for command execution

Cline → Settings → Auto-approve → Execute commands: off. Commands include arbitrary shell — rm, curl | sh, git push --force are all one approve away when this is on. Enable only inside a sandbox / VM with a snapshot, never on a workstation with credentials.

4. Restrict browser-tool access

The browser tool lets Cline load web pages — and any page it loads can contain prompt injection that hijacks the conversation. Disable the browser tool for sensitive workflows: Cline → Settings → Tools → Browser → Disabled. Re-enable on demand for tasks that genuinely need it; never leave on for long autonomous runs. See indirect prompt injection for the recurring shapes.

5. Set explicit approval requirements

The right starting config: file reads auto-approved, file edits prompt, command execution prompt, browser tool disabled. This costs you a click per action but keeps the blast radius bounded. Audit your cline_settings.json after every config change to confirm.

Recommended Steps

6. Review generated code with the same standards as a human PR

Cline’s diffs are fast and look plausible. Check: parameterized SQL queries, validated request bodies, auth on new routes, no child_process.exec with user input, no fs.readFile paths from user input without restriction.

7. Configure allowed directories with .clineignore

Create .clineignore at repo root with .env, *.pem, secrets/, node_modules/, .git/. Cline skips these from context entirely. The .git/ exclusion is important — Cline reading your git history wastes context and may surface old credentials still present in old commits.

8. Audit MCP server connections

Cline supports MCP. In Cline → MCP Servers: review every connected server. Each MCP server is a code-execution surface — read the server’s source and confirm what it accesses (filesystem, network, specific APIs). Treat MCP servers like browser extensions: minimum, vetted authors only.

9. Validate dependency suggestions

Every npm install <package> suggested by Cline goes through npm audit after install. The Package Hallucination Scanner catches the AI-specific subset of names that don’t exist on npm and have been pre-registered by attackers.

10. Set up secret detection in .clineignore AND pre-commit

Two layers: .clineignore keeps secrets out of the agent’s context; pre-commit with detect-secrets or gitleaks keeps them out of git. The first prevents the model from seeing them; the second prevents the agent’s edits from accidentally committing them.

11. Monitor API costs

Cline’s autonomous loop can burn through tokens fast — long file reads, large diffs, retries. In your provider dashboard (Anthropic Console, OpenAI Platform), set a hard budget cap and an alert at 50%. Without a cap, an infinite loop in a long task is a four-figure bill before you notice.

12. Review generated tests

Cline-generated tests often cover only the happy path. After it produces a feature, ask explicitly: “now write tests for: invalid input, missing auth, wrong-user authorization, oversized input, concurrent updates.” The security-relevant cases need to be requested by name.

13. Configure auto-approve carefully

If you do enable any auto-approve: enable read tools only (read file, read directory). Never auto-approve edit, command, or browser. The audit shape is “what’s the worst single action this can take without my consent” — the answer should always be “read a file.”

14. Audit generated Docker / IaC configs

If Cline generates a Dockerfile, docker-compose.yml, or Terraform: audit for --privileged, exposed ports without expose scoping, root user inside the container, and 0.0.0.0/0 security group rules. AI-generated infra ships with permissive defaults.

15. Keep Cline updated

Cline is open-source and iterates fast. Watch the GitHub releases for security-relevant changes and pin to a known-good version in your team if you can’t update on the same day.

16. Run an automated security scan

After Cline ships changes to production, the Vibe Code Scanner covers the deploy-side patterns; the full VibeEval scan adds BOLA and webhook trust.

Related Resources

Free Self-Audit Suite

Five free scanners.

Vibe Coding Security Risk Guide

Full risk catalogue.

Indirect Prompt Injection

Why browser-enabled agents are higher-risk and how to scope them.

Automate Your Security Checks

VibeEval scans applications shipped via Cline — every category above plus the long tail.