Connect Goose to LyraShield via MCP

Follow the current goose 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.

The vibe coding security guide separates generated code from the controls that enforce what it may do. Wiring LyraShield into Goose puts release assurance inside the agent 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
Configure	Current client guide	Manually merge the documented server entry
Manual path	~/.config/goose/config.yaml	Fallback if CLI is unavailable
Verify	npx -y lyrashield@0.2.14 doctor	Check config and credentials
Inline check	npx -y lyrashield@0.2.14 scan	Run a scan from the session
CI gate	.github/workflows/lyrashield.yml	Diff aware gate on pull requests

1. Meet the prerequisites

Install Node 24 or later, which the Node.js release guide covers. Confirm git is configured for your repository. Create a LyraShield account at lyrashieldai.com if you do not have one, because the MCP server needs credentials to authenticate. Run npx -y lyrashield@0.2.14 login to store your credentials in ~/.lyrashield/credentials.json, which is not committed to version control.

Goose does not use a rules file. Project specific instructions live in a .goosehints file in the project root, which is the main project level instruction source. 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 extension

Follow the current goose 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. Manually merge the YAML extension in ~/.config/goose/config.yaml, preserving existing extensions. The extensions map is a nested YAML structure, not a mcpServers key. A local extension uses type stdio with cmd and args. A remote extension uses type streamable_http with uri and headers. The Model Context Protocol specification defines the transport and tool exposure contract.

If the CLI is unavailable, add the entry manually. This is the manual path and it is exactly what the CLI prints. For a remote extension:

extensions:
  lyrashield:
    type: streamable_http
    uri: https://app.lyrashieldai.com/api/mcp
    headers:
      Authorization: Bearer lsk_YOUR_TOKEN

For a local stdio extension:

extensions:
  lyrashield:
    type: stdio
    cmd: npx
    args: -y @lyrashield/mcp@0.2.12

Keep any headers or credentials in environment variables referenced by the config, never as literal strings in the YAML.

3. Verify the connection

Restart the client and inspect the server and tools in its own MCP settings. Call lyrashield_list_workspaces and retain the authenticated read-only result. CLI npx -y lyrashield@0.2.14 doctor can inspect local credentials and setup, but does not prove that this client discovered tools or completed authentication. If discovery fails, check the client-specific path, root key, transport and selected workspace before requesting any recorded assessment. A configuration entry is not a scan receipt, and a successful read call is not evidence that the target application has been tested.

Restart your Goose session after editing the config file so the agent loads the new extension. Confirm the LyraShield tools appear in the session. If the tools are missing, check the type and uri spelling, the token and whether the extension is enabled. Discovery, authentication and assessment are separate checks. Reopen the client settings after changes, repeat a read-only call and preserve unresolved failures. Do not request a paid scan merely to troubleshoot configuration.

4. Run an inline security check

With the connection verified, run npx -y lyrashield@0.2.14 scan from your project root. The scan targets the repository, reviews the code for candidate issues and records evidence in a checksum-bound assurance record. Detected issues stay in a detected state until a fresh applicable retest confirms the behavior, so a finding is a prompt to investigate, not a verdict. Read each finding in the session, note the file and line and decide whether the candidate reflects a real weakness or a false positive that deserves a recorded dismissal. The assurance record holds both the confirmed issues and the dismissed ones, so a reviewer can see the full set of decisions, not just the open items.

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 hints snippet to .goosehints

Tell Goose to use LyraShield before proposing a fix. Add a line to .goosehints 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 hints 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 .goosehints in normal code review and branch protection. The Claude Code security workflow covers a related terminal agent if your team uses multiple tools.

Why pair Goose with LyraShield

Goose accelerates implementation as the open source agent from Block. 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. Approval gated fix proposals are approval-gated fix proposals, not unattended fixes. 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 Lovable app security checklist covers a related tool if your team uses multiple agents.

---

All 8 posts pass on the first sweep. The validator script and the combined file are saved in the workspace if you want to re-run checks or hand off to a developer for publishing.