Kilo Code MCP security workflow before you ship
Configure LyraShield AI with Kilo Code via MCP to run bounded scans per target, preserve evidence states and enforce diff aware gating on pull requests.

On this page
Follow the current kilo-code 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.
You can connect Kilo Code to LyraShield AI over MCP to get target aware scans, recorded evidence states and fix proposals inside your normal agent loop. This guide uses the current Kilo contract and the pinned @lyrashield/mcp@0.2.12 package.
Vibe coding moves fast and security debt can accumulate when large batches of routes, components and queries are generated in one pass. If your team uses Kilo Code to scaffold features, you want verification that matches that speed. A good starting policy is the vibe coding security guide which frames prompt hygiene, review checkpoints and supply chain checks. For context on what to look for, see OWASP Top 10 and CWE Top 25, both of which confirm injection, broken access control and vulnerable dependencies remain top risks in generated web apps.
When you generate code with an agent, you generate more attack surface than a human would in the same window. That is why early target aware scanning matters. The workflow below keeps scanning close to generation, then enforces a consistent gate in CI so main stays clean even when generation velocity spikes.
1. Prerequisites and workspace baseline
Start with Node.js 24 or newer which you can confirm via Node.js docs, Git with pull request workflow and a LyraShield API key in the form lsk_… Set the key as an environment variable named LYRASHIELD_API_KEY and avoid pasting raw values into checked in files. Kilo Code resolves {env:LYRASHIELD_API_KEY} at runtime, so secrets stay out of kilo.jsonc.
Take stock of the app scope you want to protect. LyraShield combines bounded repository review, SCA, secrets scanning, a GitHub Action and SARIF output. Findings retain their recorded evidence states; scan detection alone is not a retest. Fix proposals and retests remain approval-gated and PR execution remains unavailable until a server-generated patch can be bound to an exact approval. Read Model Context Protocol for why stdio works locally and streamable HTTP fits remote hosting.
Quick sanity checks for the MCP package and env wiring:
node -v
npm view @lyrashield/mcp version
export LYRASHIELD_API_KEY=lsk_your_key_here
npx -y lyrashield@0.2.14 doctor
For a concrete remediation checklist that mirrors your stack, keep a sibling reference such as Kilo Code app security checklist open while you implement. It helps you map a recorded finding to a specific fix pattern without guessing.
Also confirm that your repository has a clear target definition. LyraShield uses target as the unit of verification. That could be staging web, production API or a preview deployment. Deciding the naming convention before you wire MCP avoids permission confusion later, especially when you add the remote server alongside local. Teams that name targets after deploy environments usually have the least confusion during triage, because a finding is instantly tied to where it was observed.
2. Configure LyraShield MCP server in Kilo Code
Kilo Code reads MCP servers from kilo.jsonc or .kilo/kilo.jsonc in a project and ~/.config/kilo/kilo.jsonc globally. Entries live directly under the top-level mcp key. Local servers use a command array and environment; remote servers use url and headers.
{
"mcp": {
"lyrashield": {
"type": "local",
"command": ["npx", "-y", "@lyrashield/mcp@0.2.12"],
"environment": {
"LYRASHIELD_API_KEY": "{env:LYRASHIELD_API_KEY}"
},
"enabled": true
},
"lyrashield-remote": {
"type": "remote",
"url": "https://app.lyrashieldai.com/api/mcp",
"headers": {
"Authorization": "Bearer {env:LYRASHIELD_API_KEY}"
},
"enabled": true
}
}
}
The canonical reference lives in Kilo Code integration guide. Kilo permissions are configured separately under the top-level permission key with exact tool names or globs; they do not belong inside an MCP server entry.
If you manage config centrally, store the global file at ~/.config/kilo/kilo.jsonc with the same shape and let projects inherit it.
3. Verify connection and list security tools
Restart Kilo Code after editing the config. Open the MCP panel and expect lyrashield and lyrashield-remote to show connected with green status. If either shows disconnected, confirm that LYRASHIELD_API_KEY is exported in the shell that launched Kilo Code and that no corporate proxy blocks the remote endpoint.
Ask the agent to enumerate tools:
Prompt: List MCP tools from lyrashield and lyrashield-remote.
Show transport type and tool names.
Expected result:
Available MCP tools from lyrashield:
- lyrashield_scan_target(targetId, goal, mode)
- lyrashield_get_findings(targetId)
- lyrashield_list_targets()
- lyrashield_get_scan_status(scanId)
- lyrashield_generate_fix_plan(findingId)
- lyrashield_record_fix_proposal(findingId, summary)
Remote lyrashield-remote:
- lyrashield_scan_target, lyrashield_get_findings, lyrashield_list_targets
- lyrashield_get_scan_status, lyrashield_generate_fix_plan, lyrashield_record_fix_proposal
For supply chain background, skim OSV database to see how dependency advisories are structured and GitHub Actions docs to understand how secrets and SARIF flows operate. These references help you interpret SCA results that surface alongside appsec findings. Seeing both servers list the same core tools confirms that auth propagates correctly for stdio and http.
4. Run an inline security check from your agent
With tools listed, run a focused scan from inside Kilo Code rather than switching to a dashboard. The intended core loop is Target to Scan to Evidence State to Fix Proposal to Retest to Assurance Report. Use a prompt that preserves evidence states instead of flattening every detection into a verified claim.
Prompt for Kilo Code agent:
Scan target staging-web using lyrashield_scan_target.
Scope limit: src/app/api, src/lib/engines.
Return findings with their recorded evidence state, CWE, evidence snippet, file and line.
Include OWASP mapping when applicable.
Save report id for PR gate.
A good response contains finding id, severity, evidence state, file path, evidence and suggested patch location. Prioritize retest-confirmed findings while retaining detected and inconclusive items for triage. For context on categories, see OWASP Top 10 and CWE Top 25 again for category definitions and examples. Do not claim fixes, branches or PRs exist unless the corresponding action completed.
This inline check is also where you catch secrets that were generated into sample env files. LyraShield v1 includes secrets scanning alongside SCA, so a single scan can surface both hardcoded credentials and vulnerable packages. When evidence points to a config file, rotate the secret first, then fix the code path that introduced it.
5. Wire a diff aware GitHub Action gate
Local scans catch issues early, but teams need PR level enforcement that only touches changed code. Wire the official GitHub Action in diff aware mode and upload SARIF for native annotations.
name: lyrashield security gate
on:
pull_request:
paths:
- "src/**"
- "app/**"
- "packages/**"
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
Require the security job in branch protection settings. The pairing of MCP for local dev plus the Action for CI mirrors the Model Context Protocol idea of keeping context close to the agent while enforcing policy in CI. See GitHub Actions docs for reusable workflows and Model Context Protocol for transport details. Once required, developers cannot merge when findings meet the configured severity gate; that policy does not turn a detected finding into a retest-confirmed one.
6. Add agent rules for consistent secure coding
Add a repo level rules file that Kilo Code reads on each run. This makes the workflow repeatable for teammates using vibe coding patterns.
# Security rules for Kilo Code
- Before finishing a feature, call lyrashield_scan_target on changed scope.
- Surface findings with CWE, file evidence and their recorded evidence state.
- For high severity findings, generate and record a fix proposal; do not claim a branch or PR was created.
- On every PR, ensure lyrashield security gate passed and SARIF uploaded.
- Reference OWASP Top 10 and internal vibe coding security guide in PR descriptions when relevant.
- Never include secrets in logs or code. Use {env:LYRASHIELD_API_KEY}.
Store the file as .kilo/rules.md or kilo.md in your repo root so it travels with the code. This turns the core loop into daily behavior and reduces the chance that a teammate forgets to run the check during rapid iteration. It also makes security expectations visible to code reviewers, because the same rules they see in the PR description are the rules the agent followed while generating the change.
| Stage | What Kilo Code does | What LyraShield adds | Verification signal |
|---|---|---|---|
| Generation | Scaffolds routes and queries from prompts | N/A | Prompt review |
| Local check | Calls MCP tools from editor | Target aware scan plus SCA plus secrets with evidence | Finding id with CWE and file path |
| PR gate | Pushes diff to GitHub | Diff aware scan plus SARIF plus fail on high | GitHub check green and annotations |
| Remediation | Reviews and applies an approved proposal | Recorded fix proposal and server-owned retest | Retest outcome plus scan reference |
Why pair Kilo Code with LyraShield
Kilo Code gives you fast scaffolding and agent controlled edits, but fast generation still needs bounded review. LyraShield records findings with explicit evidence states, maps each issue to OWASP Top 10 and CWE Top 25, checks dependencies using OSV and keeps the loop inside MCP so you avoid context switching. The configured gate and SARIF output make triage visible where developers already work without claiming that every detection is retest-confirmed.
Close the loop with the working checklist: walk through AI app security checklist on each release candidate and confirm your config matches Kilo Code integration guide. When you are ready to evaluate managed scanning, create an account at LyraShield AI and keep the PR gate as your source of truth for verification.
Frequently asked
Where does Kilo Code store MCP server config?
Project kilo.jsonc or .kilo/kilo.jsonc or global ~/.config/kilo/kilo.jsonc, under the top-level mcp key. Use type local for stdio and type remote for HTTP.
Do I need to expose my API key in config?
No. Reference {env:LYRASHIELD_API_KEY} in env or headers. Kilo Code resolves env at runtime so the key stays out of checked in files.
Can this gate pull requests?
Yes. Wire the LyraShield GitHub Action in diff aware mode to comment on PRs and upload SARIF, then require the check in branch protection.
Where does Kilo Code read MCP server config from?
Follow /docs/integrations/kilo-code for manual setup. Use pinned CLI commands for documented config or skill installs; marketplace plugins remain separately gated. Use CLI 0.2.14 and MCP 0.2.12 for local stdio, then verify discovery and a read-only client call.
Related posts
- Amp App Security Checklist
Practical checklist for Amp: scope orbs, MCP servers, skills and CI gates before shipping AI-built code to production.
- Amp MCP security workflow for agent scans
Set up LyraShield AI with Amp via MCP to scan changed code, verify findings and enforce a diff aware GitHub Action gate with SARIF.
- Claude Code MCP Agent Rules Security Setup
Configure LyraShield MCP with Claude Code agent rules to catch OWASP risks secrets and dependency issues across local and remote MCP