Kiro MCP Security Workflow With LyraShield AI

This workflow sets up the LyraShield MCP security workflow for Kiro so the agent can run security checks inside your project. It uses pinned direct MCP while the native Power remains in preparation, then covers local OAuth and manual configuration, 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 touch Kiro, 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. Configure Kiro’s direct MCP fallback

The LyraShield Power remains in preparation; do not install a mutable candidate or treat a portable plugin copy as a supported Power import. Follow the current Kiro integration guide and Kiro’s supported MCP settings for the selected IDE or CLI version. Native Power availability, skill discovery, MCP configuration and credential authorization are different checks. The Agent Plugins specification describes a package format, but it does not establish that a particular package is published or accepted by Kiro. Keep candidate artifacts out of customer onboarding until a matching immutable release is reviewed and read back.

Merge only the LyraShield server entry into project .kiro/settings/mcp.json or user ~/.kiro/settings/mcp.json, preserving existing servers and settings. Use command: "npx" and args: ["-y", "@lyrashield/mcp@0.2.12"] under mcpServers.lyrashield. Authenticate local stdio with npx -y lyrashield@0.2.14 login --oauth in the same OS account. Use pinned CLI commands for documented config or skill installs; marketplace plugins remain separately gated. A future installer receipt cannot substitute for runtime evidence from the released package.

3. Keep authentication separate from configuration

The local stdio server reads the user-only LyraShield credential store. Do not put a raw credential in project JSON, prompts, skill Markdown, shell transcripts or repository history. Each user signs in separately and selects an authorized workspace. Sharing a credential file would share that person’s authority and obscure whose authorization a tool call used. Keep the file outside the working tree, and rotate any credential that may have entered shared source or troubleshooting output. The Model Context Protocol transport documentation explains the difference between a spawned stdio server and a hosted endpoint.

A hosted setup requires the client’s own documented authentication flow. A private read-only API key authorizes read access only and does not substitute for browser-confirmed hosted delegation. Local CLI OAuth is not automatically a login to a remote client. Check the selected surface’s current guide before changing transport; an endpoint in JSON does not demonstrate that the client can perform the necessary sign-in. Keep project trust and tool approval explicit when the client loads configuration supplied by a repository.

4. Verify discovery and a read-only call

Restart Kiro and inspect its MCP settings to confirm the server and tools are discovered. Then call lyrashield_list_workspaces and retain the authenticated result. A successful npx -y lyrashield@0.2.14 doctor result belongs to the local CLI surface; it does not validate a Power manifest, establish Kiro discovery or prove scan completion. If discovery fails, inspect the path, root key, pinned command and client version. If authentication fails, inspect the user account and selected workspace without copying credentials into the configuration.

Only request a recorded scan when the target, scope and profile are explicitly authorized. Read the resulting scan identity, revision, coverage and evidence states separately from the connection check. Detected findings remain candidates, incomplete coverage remains visible and a fix requires a fresh retest receipt. A working connection can be useful for read-only launch-readiness review without authorizing new paid work. Repeat discovery and a read call after changing the client or server entry, and repeat the assessment after the application revision changes.

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. The scan command uses --diff with the base and head SHAs, so it only analyzes files touched by the pull request, which keeps the gate fast and focused on new risk rather than re flagging pre existing issues. The SARIF upload surfaces findings in the Security tab, so reviewers see them in the same place as other code scanning results without switching tools.

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

Candidate Power instructions are not installed by this fallback. Keep your project rules focused on how the team should use the workflow. A short snippet tells Kiro 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.

A rule like attach the findings link gives the agent a concrete artifact to produce, while a vague rule like be secure leaves it guessing at what evidence counts.

Workflow step	Command or action	Purpose
Authenticate	npx -y lyrashield@0.2.14 login	Store credentials locally
Configure MCP	Current Kiro guide	Manually merge the pinned server
Verify	Kiro MCP settings and read call	Confirm discovery and authentication
CI gate	GitHub Action on diff	Block on new findings

Why pair Kiro with LyraShield AI

LyraShield AI gives you release assurance for AI built apps through a target, review, evidence, fix, retest, report loop. For Kiro 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. Detected candidates, retest outcomes and inconclusive results remain distinct. The assurance record captures its scope, what was checked and the evidence available for review. 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.