Amp MCP security workflow for agent scans

You can wire Amp directly to LyraShield AI via MCP to get target aware verification inside your agent loop. In this guide you will add the local stdio server using pinned npx -y @lyrashield/mcp@0.2.12 and the remote server at https://app.lyrashieldai.com/api/mcp with bearer auth, confirm tool listing, run a scoped scan for findings with recorded evidence states and enforce a diff aware GitHub Action gate that uploads SARIF for code scanning.

Vibe coding with Amp is fast because the agent fills in routes, components and API handlers from short prompts. Speed amplifies both delivery and risk, which is why early verification matters. A solid policy reference is the vibe coding security guide that outlines hygiene, review checkpoints and supply chain controls. For category background, consult OWASP Top 10 and CWE Top 25 to map common issues in generated front ends and APIs to concrete weakness types.

LyraShield AI is designed to keep the loop of Target to Scan to Evidence State to Fix Proposal to Retest to Assurance Report inside MCP, so you do not leave the editor to get proof. That loop is intentionally human reviewed at the PR stage, which aligns with how most teams already ship. 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 project setup

You need Node.js 24 or newer, Amp installed and logged in, Git and a LyraShield OAuth login. The local MCP package reads LyraShield’s credential store. Amp settings support ${VAR_NAME} interpolation when a separate environment value is required.

LyraShield v1 scope is agentic pentest plus SCA plus secrets plus GitHub Action plus SARIF. Current MCP tools scan, read findings, record fix proposals and queue retests. They do not edit code or open branches or pull requests, so remediation remains developer-controlled. Check Model Context Protocol for transport options and Node.js docs if you need to upgrade Node for stdio stability. Node 24 improves stdio reliability for long running MCP sessions, which matters when Amp keeps servers alive across tasks.

Verification starts with package existence and key presence:

npm view @lyrashield/mcp version
echo $LYRASHIELD_API_KEY | wc -c

Keep a stack specific reference nearby like Amp app security checklist for fix patterns while you build the workflow. That checklist translates a finding with a recorded evidence state into a concrete code change, such as stricter query binding or a dependency upgrade, without hunting through generic docs.

Define your target naming convention early. LyraShield treats target as the unit of verification, for example staging amp app, production api or a preview deployment id. A clear naming scheme avoids confusing local scans with production when you add both stdio and remote servers.

2. Configure LyraShield MCP server in Amp

Amp supports two ways to add MCP servers. The CLI path is simplest for quick setup, while settings.json gives you fine grained control for team wide defaults and deterministic behavior across clones.

CLI option for local stdio:

amp mcp add lyrashield -- npx -y @lyrashield/mcp@0.2.12
amp mcp remote --personal add LyraShield https://app.lyrashieldai.com/api/mcp --auth oauth

Settings.json option for project local or user global config:

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

This pins stdio to @lyrashield/mcp@0.2.12. The canonical reference lives in Amp integration guide. Workspace definitions require Amp approval before they run; user settings and remote definitions have separate trust and authentication paths.

3. Verify connection and list security tools

Restart Amp or reload servers after editing config. In the Amp MCP view, expect lyrashield and lyrashield-remote to show connected. If one shows retrying, check that LYRASHIELD_API_KEY is exported in the launch shell and that network policy allows egress to api.lyrashieldai.com. Corporate proxies often block the remote endpoint while allowing local npx execution, which produces a confusing half connected state.

Use a prompt to confirm tools:

Prompt: From Amp, list tools exposed by lyrashield and lyrashield-remote.
Show command type and tool names.

Expected response:

lyrashield (stdio via npx -y @lyrashield/mcp@0.2.12):
- lyrashield_scan_target(target, scope)
- lyrashield_get_findings(id)
- lyrashield_list_targets()
- lyrashield_record_fix_proposal(finding_id)
- lyrashield_create_report(targetId, audience)

lyrashield-remote (http at https://app.lyrashieldai.com/api/mcp):
- lyrashield_scan_target, lyrashield_get_findings, lyrashield_list_targets

For deeper context on what SCA surfaces, browse OSV database and for CI wiring consult GitHub Actions docs. These help you interpret findings once scans run. Seeing the same finding id in both local and remote listings confirms that your auth carries across transports, which is important when you later rely on the remote server for shared reporting.

4. Run an inline security check from Amp

With tools confirmed, run a scoped scan without leaving the agent. Keep scope tight to changed files so feedback stays fast and relevant. A narrow scope also reduces fatigue, since you only see evidence for code you just touched rather than the entire historical surface.

Prompt for Amp agent:
Use lyrashield_scan_target for target staging-amp-app.
Scope: src/app/api, src/components. Exclude tests.
Return findings with their recorded evidence states, CWE, supporting evidence, file, line and severity.
If OWASP mapping exists, include URL from https://owasp.org/www-project-top-ten/.
Store report id for later PR gate.

A useful result should include finding id, severity, recorded evidence state, CWE, file path and line, evidence snippet, limitations and suggested patch location. Prioritize retest-confirmed findings when a clean retest exists, while retaining detected and inconclusive items for triage. For definitions, read OWASP Top 10 and CWE Top 25.

Keep the loop human reviewed. lyrashield_record_fix_proposal records the intended remediation; it does not edit code or open a branch. After a developer applies the change, lyrashield_verify_fix queues a retest whose outcome must be polled and reported with its evidence state.

5. Wire a diff aware GitHub Action gate

Local Amp checks are excellent for fast feedback, but teams need PR enforcement that works even when a teammate skips the local step. Wire the official Action in diff aware mode and upload SARIF so findings appear as code scanning annotations.

name: lyrashield security gate
on:
  pull_request:
    types: [opened, synchronize, reopened]
    paths:
      - "src/**"
      - "app/**"
  push:
    branches: [main]

jobs:
  security:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - name: LyraShield diff scan
        uses: ecryptoguru/lyrashield-ai@v2
        with:
          fail_on_severity: HIGH

Enable branch protection to require the security job before merge. The runner-local Action uploads advisory SARIF annotations for the changed files; it does not reproduce Amp’s hosted finding IDs or evidence states. Use a separate recorded scan when you need retained evidence and retest semantics. For workflow reuse, see GitHub Actions docs and for protocol context see Model Context Protocol.

6. Add agent rules for consistent secure coding

Add a rules file that Amp reads on run, for example AGENT.md or .amp/rules.md in repo root. This file makes secure behavior the default rather than something you remember to type each time.

# Amp security rules

- Before marking a feature done, call lyrashield_scan_target on changed scope.
- Preserve each finding’s recorded evidence state, CWE, file location and limitations.
- For high severity, call `lyrashield_record_fix_proposal` to record the intended remediation; require human review and developer-applied code changes.
- On PRs, ensure the lyrashield security gate passed and SARIF uploaded.
- Link findings to OWASP Top 10 and internal vibe coding security guide in the PR body.
- Use $LYRASHIELD_API_KEY reference. Never log raw keys.

This file encodes Target to Scan to Evidence State to Fix Proposal to Retest to Assurance Report as daily behavior. Store it in version control so new Amp sessions inherit the same guardrails. Teammates who clone the repo get identical verification without extra setup steps, which reduces onboarding friction for fast moving teams.

Stage	Amp agent behavior	LyraShield contribution	Proof artifact
Local dev	Generates routes and API handlers from prompts	N/A	Prompt log
Inline check	Calls lyrashield_scan_target with tight scope	Findings with recorded evidence states plus SCA plus secrets evidence	Finding ids with CWE
PR gate	Pushes diff	Diff aware scan plus SARIF plus fail on high	GitHub check and annotations
Fix flow	Records a reviewed remediation proposal	No code, branch or PR is created automatically	Retest reference and status

Why pair Amp with LyraShield

Amp gives you rapid generation with strong agent control, but rapid generation wants rapid verification. LyraShield contributes recorded evidence instead of speculative warnings, maps each item to OWASP Top 10 and CWE Top 25 and surfaces dependency insights via OSV database patterns. Keeping that inside MCP avoids context switching and makes the core loop enforceable without leaving the agent. The v1 scope remains honest: agentic pentest plus SCA plus secrets plus GitHub Action plus SARIF, with broader automation on the roadmap but not billed as live today.

Wrap up by running AI app security checklist on the candidate build and confirming your config matches Amp integration guide. When ready to evaluate managed verification, create an account at LyraShield AI and keep the PR gate as your source of truth.