Connect Devin CLI to LyraShield via MCP

To connect Devin CLI to LyraShield, configure its current dedicated MCP file or use devin mcp add, then restart Devin and make a read-only tool call. Devin CLI is separate from Devin Desktop and Windsurf. Current versions document both local stdio and remote HTTP with OAuth; earlier versions stored servers in the main config and migrate them on startup. This workflow covers configuration, client verification, an inline check, a CI gate and a rules snippet.

The vibe coding security guide separates generated code from the controls that enforce what it may do. Wiring LyraShield into Devin CLI puts release assurance inside the terminal session, so a scan runs before a change reaches a pull request rather than only after. The steps below assume you have Node installed and an active LyraShield account.

Step	Command or file	Purpose
Prerequisites	Node 24 plus, git, LyraShield account	Prepare the environment
Install	devin mcp add or a reviewed config	Register one MCP server
Manual path	.devin/mcp_config.local.json	Local override on v3000.3+
Verify	devin mcp list, then a read call	Prove actual client connection
Inline check	LyraShield tools in the Devin session	Run an authorized target scan
CI gate	.github/workflows/lyrashield.yml	Diff aware gate on pull requests

1. Meet the prerequisites

Install Node 24 or later for local stdio and confirm git is configured for your repository. Create a LyraShield account at lyrashieldai.com if you do not have one. A remote OAuth connection authenticates in Devin’s browser flow and needs no local LyraShield CLI credential. For stdio, follow the current Devin CLI guide and run npx -y lyrashield@0.2.14 login --oauth to store local credentials outside the repository.

Devin CLI manages MCP servers with the devin mcp commands: add to register a server, login to authenticate, enable to turn a server on and disable to turn it off. Connected tools are namespaced as mcp__name, so you can see which server a tool call came from. Keep your credentials file outside the working tree and never paste a token directly into a config file the agent can read.

2. Add the LyraShield MCP server

On Devin CLI v3000.3 or newer, use .devin/mcp_config.local.json for a personal entry or .devin/mcp_config.json for a shared entry without secrets. The official Devin CLI MCP documentation also documents the user scope, remote HTTP, OAuth and automatic migration of older mcpServers entries from main config files. Check the version and existing entries before installing to avoid duplicate servers. The Devin CLI integration guide has the current LyraShield setup.

For the coordinated local stdio pin, a personal entry can look like this:

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

For remote OAuth, add {"url":"https://app.lyrashieldai.com/api/mcp","transport":"http"} as the lyrashield server instead, then run devin mcp login lyrashield. Do not configure both forms under the same name. The local override is gitignored by default; a shared definition belongs in .devin/mcp_config.json without literal secrets. Use devin mcp enable and devin mcp disable to control which server is active.

3. Verify the connection

Run devin mcp list, restart Devin CLI and ask Devin to call lyrashield_list_targets. Confirm a response from the intended workspace. npx -y lyrashield@0.2.14 doctor can check local LyraShield setup, but it does not prove Devin discovered the server or authenticated through its own OAuth session.

Confirm the LyraShield tools appear under the mcp__lyrashield namespace. If tools are missing, check the active scope and whether the server is enabled. For remote OAuth, run devin mcp login lyrashield if authentication is required; for stdio, check the local credential source and the pinned package. Do not treat a tool list alone as proof of a successful read call.

Record the Devin CLI version, operating system, active configuration scope, transport and selected workspace in the acceptance note. A result from a different client or workspace does not prove this session is connected. Recheck the read call after upgrades or when the enabled server set changes.

4. Run an inline security check

With the client read call verified, ask Devin to use lyrashield_list_targets, choose an authorized target and call lyrashield_scan_target. Keep the returned scan ID, poll lyrashield_get_scan_status to a terminal state and page through lyrashield_get_findings. A detected issue is not retest-confirmed without a fresh applicable retest. A runner-local npx -y lyrashield@0.2.14 scan is a different workflow and does not prove inline Devin MCP behavior.

Review the scan output in the session. If a candidate issue is real, a fix proposal is generated for review. Approval gated fix proposals require a human review before a patch reaches a pull request, so a fix is never automatic. As of August 2026, LyraShield v1 covers agentic pentest, software composition analysis, secrets scanning, a GitHub Action and SARIF output. Run the free AI app security checklist to see the full release review.

5. Gate pull requests with the GitHub Action

Add the LyraShield GitHub Action to your CI so every pull request is scanned. The action runs a diff aware gate, which means only changed code is scanned on each pull request, keeping the check fast enough to run on every push. Output is SARIF, which GitHub renders in the security tab. The GitHub Actions documentation covers workflow syntax and the GitHub SARIF integration explains how findings appear. Store the LyraShield token as a repository secret rather than a variable, so it stays encrypted and masked in logs. Set the diff aware flag to true so the action scans only the lines a pull request changes, which keeps the gate fast on large repositories and avoids re-scanning untouched code on every run.

Add a workflow file named lyrashield.yml under the .github/workflows directory:

name: LyraShield
on:
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: ecryptoguru/lyrashield-ai@v2
        with:
          fail_on_severity: HIGH

6. Add a rules snippet to AGENTS.md

Tell Devin CLI to use LyraShield before proposing a fix. Add a line to AGENTS.md in your project root:

Run the LyraShield scan tool before proposing a fix. Do not apply a patch until a human reviews the fix proposal. Keep detected issues in a detected state until a fresh applicable retest confirms the behavior.

A rules file states intent. The approval gate enforces it. A prompt can be changed in a pull request or ignored under pressure, but a server side gate that blocks a patch until a human binds it to an approval cannot be talked past. That is the difference between stating a policy and holding one. Require a security owner for changes to agent configuration and include AGENTS.md in normal code review and branch protection. The Codex security workflow covers a related command line agent if your team uses multiple tools.

Why pair Devin CLI with LyraShield

Devin CLI accelerates implementation as a Cognition command line agent. LyraShield AI provides release assurance through a loop of target, review, evidence, fix, retest and report. The platform keeps detected candidates, retest outcomes and inconclusive results distinct. Each receipt is limited to its stated evidence and scope, and the assurance record preserves what was checked and the result. Approval gated fix proposals require review before a patch reaches a pull request, so a fix is never automatic.

As of August 2026, LyraShield v1 covers agentic pentest, software composition analysis, secrets scanning, a GitHub Action with a diff aware gate and SARIF output. Fix proposals are approval gated and never unattended. The GitHub Action runs a diff aware gate so only changed code is scanned on each pull request. Create an account to start or run the free AI app security checklist first. The Windsurf security workflow covers a related tool if your team uses multiple agents.