Skip to content

Zed MCP security workflow for AI built apps

Connect Zed to LyraShield AI over MCP for findings with explicit evidence states and a diff aware GitHub Action gate inside your existing editor flow.

LyraShield MCP integration with Zed
On this page

Add one of the configurations below to Zed’s settings.json. Restart Zed, confirm the server in Settings → AI → MCP Servers, then make a read-only tool call from the Agent Panel. lyrashield doctor checks local setup; it does not prove that Zed discovered or called a tool.

You can secure AI built apps in Zed by connecting LyraShield AI through the Model Context Protocol and reviewing findings with recorded evidence states directly from the editor, then enforcing the same policy in CI with a diff aware GitHub Action gate. Zed reads servers from settings.json under context_servers, supporting local stdio and remote HTTP with browser OAuth or a separately configured API key.

Zed is fast and agent native, which makes it popular for vibe coding, but speed can leave security gaps when dependencies and routes are scaffolded by agents. The vibe coding security guide frames this problem as unverified generation at scale. LyraShield AI follows a loop of Target to Scan to Evidence State to Fix Proposal to Retest to Report. This post shows current Zed configuration forms and a verification path. Zed documents remote OAuth, but that is not a substitute for a real-client read receipt for your version and platform.

1. Prerequisites and setup

Use a current Zed release, Node 24 or newer for local stdio and a GitHub repo where you can add workflows. Zed reads MCP servers from settings.json under context_servers; the official Zed MCP guide documents the current flat local command and remote URL forms. Remote OAuth starts in Zed when no Authorization header is configured. Do not add a key merely to preview the setup. Restart Zed after changing settings and verify a read-only call before relying on inline findings.

2. Configure the MCP server in Zed

Zed supports local stdio and remote HTTP MCP servers. Add one of these blocks to your Zed settings.json. The full reference lives in the Zed integration guide. An older nested command.path entry should be migrated to Zed’s current flat command, args and env fields after backing up the existing settings file.

Local stdio mode:

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

Remote HTTP mode with browser OAuth:

{
  "context_servers": {
    "lyrashield-remote": {
      "url": "https://app.lyrashieldai.com/api/mcp"
    }
  }
}

The remote URL is https://app.lyrashieldai.com/api/mcp. Zed handles the OAuth browser flow for this entry; an API-key headers form is available only if your team deliberately chooses it. Local stdio uses the pinned @lyrashield/mcp@0.2.12 package and requires a valid local LyraShield credential before authenticated calls. See the Zed AI app security checklist for client-side permission review. The runner-local CI Action is a separate check and does not share hosted finding IDs by default.

3. Verify the connection in Zed

Restart Zed after editing settings.json, then open Settings → AI → MCP Servers and check for an active indicator. In the Agent Panel, call lyrashield_list_targets and confirm an actual response before starting an authorized scan. For remote OAuth, finish Zed’s browser connection flow if prompted. For local stdio, check the local credential source if authentication fails. An API-key fallback has its own credential and rotation path.

Record the Zed version, operating system, selected workspace, server transport and the returned target ID in your acceptance note. A green server indicator proves discovery, while the read response proves that this client session reached the intended LyraShield workspace. Repeat this check after a Zed or MCP package upgrade.

4. Run an inline security check from the editor

With the server green, target your current project root and run a scan from the prompt. Ask Zed to summarize each finding with its recorded evidence state. Cross-check dependencies against OSV and code patterns against CWE Top 25. lyrashield_generate_fix_plan is read-only, while lyrashield_record_fix_proposal records an approved remediation summary; neither edits code, creates a branch or opens a PR. Apply the change in your normal development workflow, queue lyrashield_verify_fix and poll the returned scan to a terminal state. Keep the loop as Target to Scan to Evidence State to Fix Proposal to Retest to Assurance Report. Call a result retest-confirmed only when a fresh applicable retest exists.

5. Wire the GitHub Action diff aware gate

Editor checks catch issues early, CI gates prevent drift on pull requests. Add .github/workflows/lyrashield.yml with a SARIF upload so results appear in GitHub code scanning. The GitHub docs for SARIF upload describe the required security-events: write permission. The workflow below uses the same pinned npx and remote endpoint pattern and keeps secretsGitHub scanning broad.

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 runs only on changed files, which keeps the gate fast and focused. SARIF output integrates with GitHub code scanning. If you need SCA and secrets history, see docs.github.com on dependency review for supply chain context. The action derives the pull-request diff, so a one-line edit avoids a full scan. SARIF lands in the GitHub Security tab, where each rule maps to a file and line. The local MCP server and the runner-local CI gate are complementary checks, not the same remote scan.

6. Add agent rules snippet

Add a short rule file so every agent session in Zed follows the same security loop. Save as .agent/rules/security.md or the equivalent rules directory you use.

# Security rules for Zed agents

- Always start with Target identification: root, env and data class.
- Run LyraShield scan via MCP before proposing large refactors.
- Treat only findings with evidence states as blocking. Include evidence in the PR description.
- For Fix Proposal, propose minimal diff, add tests for the finding with an evidence state and request retest.
- Update Report notes with scan ID and SARIF link.

This keeps behavior consistent between human and agent edits. The rule avoids phrases implying unattended fixes and frames the Fix Proposal as a proposed change designed to be reviewed. Think of the rules file as the contract your agent follows unsupervised. The first bullet forces target identification, stopping wrong directory scans. The fourth enforces approval-gated fix proposals, not unattended fixes, because the agent proposes a minimal diff.

Mode Transport Best for Env key URL
Local stdio npx -y @lyrashield/mcp@0.2.12 Local dev, offline LYRASHIELD_API_KEY internal process
Remote HTTP streamable HTTP with Bearer lsk_ Team shared keys, CI LYRASHIELD_API_KEY, LYRASHIELD_API_URL https://app.lyrashieldai.com/api/mcp
Diff gate GitHub Action + SARIF PR enforcement LYRASHIELD_API_KEY secret https://app.lyrashieldai.com/api/mcp

7. Why pair Zed with LyraShield

Zed gives you speed and agent control, LyraShield adds verification and reporting that is designed to scale with AI built code. Pillar coverage from the vibe coding security guide explains why unverified scaffolding creates systemic risk across auth, injection and supply chain. Zed runs the tools, LyraShield provides the evidence trail from Target to Scan to Evidence State to Fix Proposal to Retest to Report. v1 is scoped to agentic pentest plus SCA plus secrets plus GitHub Action plus SARIF, so you can cover both code and dependencies without adding three separate scanners. Use the Zed integration guide as the canonical config source and keep the loop explicit in pull request templates so reviewers see scan IDs and retest links.

To put this into practice, run your first scan in Zed, triage one finding with an evidence state, propose a Fix Proposal with tests and confirm the SARIF report in GitHub code scanning. Then expand your checklist with the AI app security checklist and create an account at LyraShield AI to track when Fix Proposal generation and full engine execution moves from designed to live. The pairing works because Zed minimizes friction between writing and checking, while LyraShield adds verification that generation skips.

Frequently asked

How does Zed MCP integration work with LyraShield AI?

Zed reads settings.json context_servers. Add a local command or a remote URL; a remote entry without an Authorization header starts Zed's MCP OAuth flow. Confirm discovery and call a read-only LyraShield tool in the Agent Panel.

What does the GitHub Action gate add beyond editor checks?

The diff aware gate runs on pull requests, blocks risky code paths with SARIF results and keeps retest and report steps consistent between local Zed runs and CI. It is designed to enforce the same policy for every contributor.

Does valid Zed configuration prove the integration works?

No. Restart Zed, inspect its MCP status, then make a read-only tool call from the intended workspace. Keep transport, authentication and client-side tool permissions as separate checks.

How should I manage API-key fallback credentials?

A key is only needed for the API-key fallback. Keep it outside shared settings and use encrypted CI secrets where applicable. Zed's remote OAuth path does not require a local LyraShield CLI login or an lsk_ placeholder.

Stay in the loop.

We store your email for product updates and scorecard notifications. No sharing, no marketing blasts.