Copilot CLI MCP Security Workflow Setup Guide

This workflow sets up the LyraShield MCP security workflow for GitHub Copilot CLI so the terminal agent can run security checks inside your project. It leads with the LyraShield CLI, then covers global and project config, the tools allowlist, verification, an inline check, a GitHub Action diff gate and an agent rules snippet. Pair it with the vibe coding security guide for broader context.

1. Install prerequisites and authenticate

Install Node so the npx commands resolve, then run npx -y lyrashield@0.2.14 login --oauth to store your credentials in a local file under your home directory. Nothing is committed to the repository, because credentials live in a per user file and the CLI never writes them into source. This matters for shared repos where a committed token would leak to every collaborator and to the git history. Confirm with npx -y lyrashield@0.2.14 doctor that the server is reachable and the credentials resolve before you configure Copilot CLI, because a failed login surfaces here instead of mid install. The Node.js downloads page is the canonical source for the runtime. Run login and doctor from the project root so any project scoped config is detected correctly and re-run doctor whenever you suspect the connection has drifted. If you share a machine with teammates, note that the credentials file is per user, so each person runs login once rather than sharing a single credential file.

2. Register the MCP server with Copilot CLI

Use Copilot CLI’s documented separator form for local stdio:

copilot mcp add lyrashield -- npx -y @lyrashield/mcp@0.2.12

For remote HTTP, options precede the server name and URL:

copilot mcp add --transport http --header "Authorization: Bearer YOUR-TOKEN" lyrashield-remote https://app.lyrashieldai.com/api/mcp

The user file is ~/.copilot/mcp-config.json; project files are .mcp.json or .github/mcp.json. Never put a raw header in a committed project file. See the official Copilot CLI MCP guide and LyraShield guide.

3. Set the tools allowlist and install the supported configuration

For each server entry set a tools allowlist so the agent can only invoke the tools you explicitly permit, rather than every tool the server exposes. The pinned CLI 0.2.14 can install supported MCP configurations while preserving existing settings; use the current Copilot CLI guide for the @lyrashield/mcp@0.2.12 setup. Agent Plugin 0.1.31 is published; use workflow skills only through a client-supported reviewed listing, because authenticated Copilot CLI skill discovery has not yet been accepted. Authenticate local stdio separately with CLI OAuth; hosted remote access uses its own authorization flow. Never commit a remote header or token-bearing global config. The Model Context Protocol specification defines how servers expose tools and why allowlists matter. Recheck the allowlist after any server update, because a new server version can expose tools you did not permit, and tighten it whenever a tool is no longer needed.

4. Verify the connection and run an inline check

After config, verify that Copilot CLI can reach the server by asking the agent to run a security check on the current project. The agent should call the LyraShield tools to target the app, run review and return findings you can act on. Doctor checks local setup only. Restart Copilot CLI, inspect /mcp show lyrashield, then call lyrashield_list_workspaces to confirm the expected workspace. Discovery and an authenticated read are separate checks. Ask the agent to return each finding with its recorded evidence state, file path and CWE so you can triage on the same evidence the PR gate will later block on. Run an inline check on a small change before wiring CI, because a green local run proves the credentials and transport are correct end to end. If the agent cannot see the tools, recheck the config file and the tools allowlist and confirm the server entry names the right transport. A failed inline check is cheaper to debug now than a red CI run later. If the inline check returns findings, read them before wiring CI so you understand the output format the GitHub Action will produce and so you can set expectations with your team about what a blocked build looks like.

5. Add the GitHub Action diff gate

Wire the workflow into CI so every pull request is scanned on the changed diff, not the whole repository. The LyraShield GitHub Action runs on pull request events, targets the changed files and emits SARIF output you can ingest. Approval gated fix proposals are proposals requiring review, so the action blocks only on new findings while a human approves any fix. The GitHub Actions security hardening guide describes the permissions and secret handling to apply. Run the action on every pull request so review cannot be skipped under deadline pressure and pin your action versions so an upstream change cannot alter your gate. Store any token the action needs as a GitHub Actions secret rather than in the workflow file and give the job the minimum permissions it needs, because a scanner job does not need write access to your repository contents.

name: LyraShield Security Check
on:
  pull_request:
    types: [opened, synchronize, reopened]
permissions:
  contents: read
  pull-requests: write
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: ecryptoguru/lyrashield-ai@v2
        with:
          fail_on_severity: HIGH

6. Add an agent rules snippet

Copilot CLI has no dedicated rules file, so convey conventions through the chat prompt and the config you allow. A short snippet you paste into the session tells the agent to run a check before completing a feature and to attach evidence to the pull request.

Before finishing a feature, run a LyraShield security check and attach the findings link to the pull request. Never commit secrets. If a high severity issue is found, stop and ask for review.

Workflow step	Command or action	Purpose
Authenticate	npx -y lyrashield@0.2.14 login –oauth	Store credentials locally
Register server	copilot mcp add	Add server consistently
Restrict tools	tools allowlist field	Permit only needed tools
CI gate	GitHub Action on diff	Block on new findings

Why pair Copilot CLI with LyraShield AI

Keep installation, authentication and security results as separate acceptance checks. copilot mcp list establishes that Copilot loaded the server definition. A read-only LyraShield target query establishes authenticated tool use. A recorded scan establishes only its declared target, revision and coverage. The runner-local Action establishes its own diff result and cannot be substituted for the hosted receipt. Record all four when reviewing an exact release.

Recheck the server after upgrading Copilot CLI or the LyraShield package. Confirm the config location, transport, allowed tools and credential source, then repeat one read-only query before enabling any approval-gated mutation. If access is revoked or the workspace role changes, the next call must fail rather than reuse a previous successful response. This bounded sequence gives reviewers useful evidence without claiming broader desktop acceptance than was exercised.

LyraShield AI gives you release assurance for AI built apps through a target, review, evidence, fix, retest, report loop. For Copilot CLI it contributes agentic pentest, software composition analysis and secrets scanning, then writes each finding with its scope and evidence in an assurance record; a retest-confirmed state requires a fresh applicable retest. Approval gated fix proposals are proposals requiring review, so a human stays in the loop before anything ships. The platform is live with open registration, so you can create an account and pair it with the AI app security checklist tool. For a review focused companion, see the Codex security workflow post. Running the workflow on every Copilot CLI session means a security check happens before code reaches review, not after a finding slips into production. Treat the local check and the CI gate as two layers of the same workflow, because together they cover the prompt to merge path. A consistent tools allowlist across your project and global config keeps the agent from calling a write or network tool you did not intend to expose during a fast scaffold and it travels with the repo when a teammate clones it.