Cline MCP security workflow for AI built apps

Follow the current cline integration guide and manually merge the server entry, preserving existing settings. Authenticate local stdio separately with npx -y lyrashield@0.2.14 login --oauth and use @lyrashield/mcp@0.2.12. Use pinned CLI commands for documented config or skill installs; marketplace plugins remain separately gated. Restart the client, confirm discovery, then call lyrashield_list_workspaces for authenticated read-only access. CLI doctor does not establish client authentication or scan completion.

You can run secure AI app development in Cline by adding LyraShield AI as an MCP server, getting findings with their recorded evidence states and supporting evidence inside Cline and enforcing the same checks in CI with a diff aware GitHub Action that uploads SARIF.

Cline automates file edits and terminal actions, which speeds up feature work but can introduce secrets, injection and vulnerable dependencies when scaffolding is agent driven. The vibe coding security guide explains why verification must be part of the agent loop. LyraShield AI is agent native AppSec for AI built software with a loop from Target to Scan to Evidence State to Fix Proposal to Retest to Assurance Report. This guide gives exact Cline config using npx -y @lyrashield/mcp@0.2.12 and https://app.lyrashieldai.com/api/mcp, verification, inline checks and the GitHub gate. Findings retain their recorded evidence states. Current LyraShield tools record fix proposals and queue retests but do not edit code, create branches or open pull requests.

1. Prerequisites and setup

You need a current Cline extension or CLI, Node 24 or newer and permission to add workflows. Cline CLI reads ~/.cline/data/settings/cline_mcp_settings.json; IDE extensions open their client-owned settings JSON from MCP Servers → Configure. Both use mcpServers. Local entries use command and args; remote entries use type: "streamableHttp", url and optional headers. See the official Cline MCP documentation and the Cline integration guide.

2. Configure Cline MCP servers

Use the Cline MCP panel or edit ~/.cline/data/settings/cline_mcp_settings.json for Cline CLI. The safe default is local stdio with the credential store created by lyrashield login --oauth.

Local stdio:

{
  "mcpServers": {
    "lyrashield": {
      "command": "npx",
      "args": ["-y", "@lyrashield/mcp@0.2.12"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

For remote mode, open Cline’s Remote Servers tab, enter https://app.lyrashieldai.com/api/mcp, choose Streamable HTTP and add the Bearer header in Cline’s private settings. Cline’s current guide does not document environment interpolation in headers, so do not paste an interpolation expression and assume it resolves. For related editor checklists, see the Cline AI app security checklist.

The autoApprove array controls which tool names run without your confirmation. Every entry you list there executes immediately, so treat it as a privilege grant. For a security scanner, keep autoApprove empty or limited to read only tools like lyrashield_get_scan_status and lyrashield_list_targets and leave fix and retest tools gated behind your click.

3. Verify the connection in Cline

Reload the Cline client after changing its settings, then open the MCP Servers panel. You should see lyrashield listed as active. Call a read-only status tool. If the server stays disabled, set disabled: false and reload. Keep autoApprove minimal because each listed tool can run without another confirmation.

A local authentication failure usually means the LyraShield credential store is missing or expired; repeat lyrashield login --oauth. If remote mode connects but tool calls time out, verify that the private header is current and that your network allows outbound HTTPS to https://app.lyrashieldai.com.

4. Run an inline security check from Cline

Prompt Cline: “using LyraShield MCP, scan the authorized target, preserve every finding’s evidence state and group findings by auth, injection, secrets and supply chain.” Use lyrashield_scan_target for the scan, lyrashield_get_findings for results, lyrashield_record_fix_proposal for the intended remediation and lyrashield_verify_fix only after a developer applies the change.

Example rules you can store in .clinerules/security.md:

# Security loop for Cline

- Define Target: app root, entry points, sensitive stores
- Scan via LyraShield MCP before finalizing large edits
- Treat findings with their recorded evidence states and supporting evidence as blocking
- Create fix proposal summary, include tests, request retest
- Append Report with scan ID and SARIF link

An approval-gated fix proposal is a recorded remediation summary, not a patch, branch, pull request or merge. The developer applies the code change; lyrashield_verify_fix then queues a retest and returns a reference to poll.

5. Wire the GitHub Action diff aware gate

Add .github/workflows/lyrashield.yml with SARIF upload, as per GitHub docs for SARIF upload.

name: lyrashield diff gate
on:
  pull_request:
    branches: [main]
permissions:
  contents: read
  security-events: write
  pull-requests: write
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: ecryptoguru/lyrashield-ai@v2
        with:
          fail_on_severity: HIGH

This workflow runs the published action’s local diff advisory on the pull-request changes. It does not call the remote MCP endpoint, use Bearer authentication or require LYRASHIELD_API_KEY and its heuristic output is not a recorded scan or a retest result.

The diff-aware design matters because Cline sessions often touch dozens of files in a single prompt. The action evaluates the changed lines supplied by the pull-request context and applies the configured severity threshold. Treat it as a fast advisory gate; use a separate recorded LyraShield scan when you need persisted findings, evidence states, coverage receipts or an assurance report.

6. Add agent rules snippet for team use

Commit a shared rule file so all contributors get the same behavior. This also helps new engineers link the pillar doc correctly as vibe coding security guide rather than a bare URL.

# Team security rules

- Always include Target description in PRs that touch auth or data.
- Run LyraShield scan via MCP before requesting review.
- Include evidence for each finding with a recorded evidence state in PR body.
- Record a fix proposal with minimal diff, add regression test.
- Link SARIF artifact and scan ID in Report footer.

This codifies consistent security behavior between Cline, GitHub and other editors. For deeper supply chain context, see NIST SSDF and OWASP Top 10 as primary sources.

Agent rules work because Cline reads .clinerules files at the start of every session and treats them as standing instructions. When you commit .clinerules/security.md to the repository, every contributor gets the same scan requirement without reading a wiki page. Keep rules short and imperative, five to seven lines maximum, because long rule files dilute attention. Pair the rules with a PR template that asks for the scan ID and SARIF link.

Mode	Config file	Launch style	Auth
Local	~/.cline/data/settings/cline_mcp_settings.json or IDE-managed settings	npx -y @lyrashield/mcp@0.2.12	LyraShield OAuth credential store
Remote	IDE-managed settings	streamableHttp	Private Bearer header
CI gate	.github/workflows/lyrashield.yml	ecryptoguru/lyrashield-ai@v2	no LyraShield secret required

7. Why pair Cline with LyraShield

For acceptance, record the Cline host and version, whether the CLI or IDE-owned settings file supplied the server, the LyraShield package version, transport, authenticated read result and any approval decision. Reload after revocation or permission changes and repeat the read so a cached tool list is never mistaken for current workspace access.

Keep that receipt with the exact source revision and test date.

Cline gives you autonomous edit loops, LyraShield adds verification that records its scope, evidence and limitations. The vibe coding security guide explains how fast agent loops without verification raise systemic risk across auth, injection and secrets. The core problem is speed without proof: Cline can scaffold a full feature in minutes, but every generated file is unverified until someone reviews it. Pairing keeps your flow in Cline but your policy in one place: findings with recorded evidence states, recorded fix proposals, retest and SARIF reports that GitHub understands per docs.github.com on code scanning. LyraShield v1 includes agentic pentest plus SCA plus secrets plus GitHub Action plus SARIF. Bounded scans, evidence states, fix-proposal recording, retest queueing and SARIF are available now.

To start, add Cline MCP servers, verify tool list, run a diff scan on your next AI generated branch, triage one finding with its recorded evidence state and supporting evidence, record a fix proposal with tests and confirm SARIF in GitHub code scanning. Expand coverage using the AI app security checklist and create an account at LyraShield AI to centralize results across sessions.