Claude Code security workflow for AI built apps

Claude Code reads your repo, edits many files, runs commands and calls MCP tools in one session, so you need scoped permissions and locked down config. This workflow shows how to harden .mcp.json across local, project and user scopes, limit tool permissions, gate secrets and dependencies and collect SARIF for every pull request. Pair it with LyraShield as release assurance for AI built apps. See our vibe coding security guide for baseline controls before applying Claude Code specific checks.

Understand Claude Code risk surface

Claude Code operates with your shell permissions and broad file access. A single prompt can add packages, change auth middleware and connect a new MCP server. That compression of work is productive but concentrates risk, especially when production credentials are loaded in the same shell.

Common patterns seen in AI assisted code include leftover debug endpoints that skip auth, hardcoded test secrets that become real credentials and transitive dependencies added without review. Use consistent references when you file tickets so severity is clear to reviewers.

OWASP Top Ten lists injection and misconfiguration as persistent app risks, see OWASP Top Ten. Credential handling maps to CWE 798 for hard coded credentials and command injection to CWE 78. MCP auth expectations are at MCP authorization spec. For visual builders, our Replit app security checklist shows similar permission ideas.

Configure MCP in .mcp.json with scoped permissions

Claude Code supports three scopes for MCP config. Local scope applies to just this session. Project scope lives in .mcp.json at repo root and is shared with the team via git. User scope lives in personal config like dot Claude dot json or .mcp.json in home and is for personal helpers. Prefer project scope for team servers that every developer needs and user scope for personal tools that should not be in git.

Follow the current claude-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.

Secure example for project .mcp.json:

{
  "mcpServers": {
    "lyrashield": {
      "command": "npx",
      "args": ["-y", "@lyrashield/mcp@0.2.12"]
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp/work"]
    }
  }
}

Add servers via CLI instead of manual JSON when possible:

{
  "note": "Commands to run: claude mcp add lyrashield --scope project -- npx -y @lyrashield/mcp@0.2.12 and claude mcp add --transport http --scope user lyrashield-remote https://app.lyrashieldai.com/api/mcp"
}

Hardening details that matter for review:

• Never store raw keys in .mcp.json. Use env var references and load from a secret manager at runtime. Check CI for literal sk or lsk patterns.
• For project scope, require pull request review for any MCP addition. Treat new servers like new production dependencies with an owner and review date.
• Limit filesystem server args to the smallest directory needed for the task. Over broad file access widens exfiltration risk.
• For hosted MCP, complete OAuth in Claude Code; a private read-only API key is a separate read-only option and cannot authorize hosted mutations. Local stdio reads the user-only credential store after CLI OAuth. Protocol and transport options are described at MCP specification.
• Verify scope behavior with vendor docs at Claude Code MCP and overview at Claude Code overview.

Log which servers were active for a feature in the pull request description. That one line helps reproduce permission issues later and keeps audits simple.

Harden rules with CLAUDE.md and settings

Use CLAUDE.md in repo root to state what the agent may and may not do. Version it in git and require review on changes.

Recommended policy blocks:

• Edit scope: allow src, tests and docs. Protect env, secrets and infra unless security owner approves. Deny direct edits to production workflow files.
• Command policy: allow read and limited test commands, require confirm for package installs and migrations, deny curl with secrets and git push to main.
• Network policy: list allowed registries and APIs the agent may call during generation and forbid arbitrary egress.

Pair that with project owned settings for approval. Prefer asking before execution for auth, payment, file upload and infrastructure code. This slows only the riskiest paths while keeping routine refactors fast.

Add a rule about plan first for broad changes. Ask Claude Code to write a short plan markdown and get approval before editing ten or more files or touching auth. That mirrors plan mode design and reduces blast radius when prompts are ambiguous.

If the agent proposes broad regex replacements, split into smaller commits with tests. Broad replacements are where credential patterns or auth bypasses are missed.

Gate dependencies and secrets before merge

Agentic edits often add npm or Python packages to solve a task quickly. That is where supply chain risk enters the repo.

Run dependency scanning on each pull request. OSV provides a broad open vulnerability database at OSV database. For Node run npm audit or pnpm audit, for Python consider pip audit. Block high severity findings outright. Document any exception with owner, risk note and expiry date. Check lockfile diffs for new transitive deps with low download count or recent maintainer change and flag those for manual review.

For secrets, run gitleaks or trufflehog in CI and locally via pre commit. Block new findings. Validate that .mcp.json, CLAUDE.md and local shell history do not contain raw tokens. The GitHub SARIF shape for secret scanning is described at GitHub SARIF for secret scanning. Keep env examples as placeholders only. Production secrets belong in your secret manager, not in agent context.

Require secret management via platform store. Verify that bearer token env var references point to env that is not echoed in logs. Check CI logs for accidental secret echo and redact quickly if found.

Capture verified evidence with SARIF and logs

Collect machine readable evidence for each release so review does not depend on memory.

Per branch procedure:

1. Run lint, type check, secret scan and dependency audit.
2. Convert each tool output to SARIF where supported.
3. Upload SARIF via GitHub Action code scanning uploader.
4. Add docs slash security evidence markdown file with date, commit, active MCP servers, tools run and reviewers.
5. Store build and SARIF artifacts with release tag.

See GitHub guidance at SARIF upload and general code scanning at GitHub code scanning. Keep artifacts for at least a few releases so you can show trend and exception closure.

If you use remote MCP, log server version used during generation. Small details like server url and timestamp help when debugging tool permission drift.

Control	File or setting	Review signal
MCP scope	.mcp.json local project user scopes	No raw keys, project scope reviewed, least directory access configured
Permission policy	CLAUDE.md plus approval settings	Plan mode for exploration, approval needed for edits outside src and for infra
Secrets gate	CI secret scan with SARIF upload	No tokens in git, env via manager, findings block merge
Dependency gate	OSV plus package audit in CI	High severity blocks, exceptions tracked with owner and expiry date
Evidence	GitHub code scanning plus security evidence file	SARIF on PR and main, MCP list logged per release, release tag linked
Release hygiene	Pull request template plus branch protection	Auth changes flagged, tests required, reviewers assigned and documented

Why pair Claude Code with LyraShield

LyraShield AI is release assurance for AI built apps, see https://lyrashieldai.com. The loop is target, review, evidence, fix, retest, report: detection stays separate from proof, recorded scans contribute to an assurance record and fix proposals are approval gated so PR execution is blocked until a server generated patch is bound to the exact approval.

MCP integration fits Claude Code. Local stdio via npx -y @lyrashield/mcp@0.2.12 uses env var keys for project scope and remote at https://app.lyrashieldai.com/api/mcp accepts Bearer lsk key with user or project scope. GitHub Action is diff aware and produces SARIF for code scanning so results appear in your pull request.

Build honesty note: LyraShield is live in open beta with open registration. The scan pipeline, findings and evidence, approval-gated fix proposals, retests, reports, billing and Local/Desktop flows are implemented. Production availability remains bounded by retained evidence and release gates; automatic server-generated Fix PR execution is not enabled; self-serve checkout is live.

This pairing keeps Claude Code speed while preserving a consistent verification narrative across editors.

Closing checks and next steps

Before merge, confirm these controls.

• .mcp.json scopes minimal, no raw secrets, reviewed in PR.
• CLAUDE.md policy lists protected paths and required approvals.
• Dependency and secret scans ran and SARIF uploaded to code scanning.
• Auth and payment changes have tests and assigned reviewer.
• Release evidence file updated with MCP servers and commit.

Apply the same evidence pattern using our AI app security checklist tool and create an account at https://lyrashieldai.com to start building assurance records today. For related multi builder flows see V0 app security checklist and Base44 app security checklist to keep controls uniform across your fleet.