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 lyrashield login 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 lyrashield 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 the copilot mcp add command to register the LyraShield server consistently, rather than hand editing the JSON, because malformed config can break the agent or leak settings into logs. For a local server use type local with stdio transport running npx -y @lyrashield/mcp. For a remote server use type http with the endpoint https://app.lyrashieldai.com/api/mcp and a Bearer token prefixed lsk_. The global config file at the user level applies to every project, while a project level file scopes the server to one repository, so prefer the project file for anything repository specific and keep the global file free of tokens. For a local stdio server, run copilot mcp add lyrashield --transport stdio --command npx --args "-y @lyrashield/mcp" so the agent spawns the MCP process inline with no network hop. For a remote server, run copilot mcp add lyrashield-remote --transport http --url https://app.lyrashieldai.com/api/mcp --header "Authorization: Bearer lsk_..." to use the managed endpoint with a bearer key. Choose local when you can run a Node process in your environment, and remote when you want a central key your team shares. The GitHub Copilot CLI documentation describes the config locations and the add command. The canonical LyraShield wiring is in the Copilot CLI integration guide. Decide between local and remote based on whether you can run a Node process in your environment, since the remote path removes the local runtime dependency. After you run copilot mcp add, open the resulting config file once to confirm the entry landed in the scope you intended, because a server meant for one project that lands in the global file becomes available everywhere.

3. Set the tools allowlist and the manual path

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 primary setup command is npx lyrashield install copilot-cli, which writes this config for you; the manual block below is the fallback path since Copilot CLI has no Agent Plugin. Store the remote token in the local credentials file rather than the project config you commit, and keep any global config that holds a token out of version control entirely, because a committed token leaks to every collaborator. 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 new tools you did not permit, and tighten the list 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. Confirm with npx lyrashield doctor that the config is valid and the server is reachable, so you know setup succeeded without a manual guess. 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 lyrashield login	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

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 to an immutable assurance record that separates detection from proof. 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.