ktg-plugin-marketplace/plugins/llm-security/commands/pre-deploy.md

name	description	allowed-tools	model
security:pre-deploy	Pre-deployment security checklist — verify enterprise controls, compliance, and production readiness	Read, Glob, Grep, AskUserQuestion	sonnet

/security pre-deploy

Running pre-deployment security checklist...

Automated Checks

Run each check and record status (PASS / FAIL / WARN / N/A).

1 — Deny-first permissions

Read .claude/settings.json and ~/.claude/settings.json. Look for "permissions" block with a deny-first or allowlist-only policy (e.g., "defaultMode": "allowList" or explicit deny rules). Status: PASS if deny-first found, WARN if not configured, FAIL if allow-all detected.

2 — Secrets hook active

Read hooks/hooks.json (or .claude/hooks.json). Check for a PreToolUse hook matching Edit|Write that references pre-edit-secrets. Status: PASS if found, FAIL if absent.

3 — Path guard active

Same hooks.json or global ~/.claude/settings.json hooks. Check for a PreToolUse hook matching Write or Edit|Write that references pre-write-pathguard. Status: PASS if found locally or globally, FAIL if absent in both.

4 — Destructive command guard

Same hooks.json. Check for a PreToolUse hook matching Bash that references pre-bash-destructive or equivalent firewall script. Status: PASS if found, WARN if absent.

5 — MCP servers verified

Read .mcp.json if it exists. For each server listed, check whether it is a known/trusted server (Linear, MS Learn, Tavily, GitHub, etc.) vs. unknown third-party. Flag any unknown servers. Status: PASS if all known, WARN if unknown servers present, N/A if no .mcp.json.

6 — No hardcoded secrets

Grep source files (excluding node_modules, .git, *.md) for common secret patterns: API_KEY, api_key, secret, password, token, bearer, sk-, -----BEGIN. Status: PASS if no hits, FAIL if hits found.

7 — .gitignore covers secrets

Read .gitignore. Check for entries covering .env, .env.*, credentials, *.key, *.pem, secrets*. Status: PASS if at least 3 of these patterns present, WARN if partial, FAIL if absent.

8 — CLAUDE.md has security section

Read CLAUDE.md. Check for a section or heading mentioning security, secrets, hooks, or permissions. Status: PASS if found, WARN if absent.

9 — Sandbox enabled

Read settings files. Check for "sandbox": true or sandbox-related configuration. Status: PASS if enabled, WARN if not configured (sandbox is opt-in).

10 — Audit logging configured

Check hooks.json for any Stop or PostToolUse hooks that write audit logs, or check settings for audit log paths. Status: PASS if found, WARN if absent.

Manual Verification

Ask the user these questions using AskUserQuestion (one at a time):

1. "Is this project deployed under an Anthropic Enterprise plan? (SSO, SCIM, and audit logging are enterprise-only controls.)"
2. "Has a DPIA (Data Protection Impact Assessment) been completed for this AI solution?"
3. "Is there a documented incident response plan for AI failures or security incidents?"

Record answers and include in the report.

Report

Generate the report using templates/unified-report.md (ANALYSIS_TYPE: pre-deploy) as the format reference. Structure:

## Pre-Deployment Security Checklist

Passed: X/10 automated checks

| # | Check                    | Status | Detail                          |
|---|--------------------------|--------|---------------------------------|
| 1 | Deny-first permissions   | ...    | ...                             |
| 2 | Secrets hook             | ...    | ...                             |
| 3 | Path guard               | ...    | ...                             |
| 4 | Destructive cmd guard    | ...    | ...                             |
| 5 | MCP servers verified     | ...    | ...                             |
| 6 | No hardcoded secrets     | ...    | ...                             |
| 7 | .gitignore covers secrets| ...    | ...                             |
| 8 | CLAUDE.md security docs  | ...    | ...                             |
| 9 | Sandbox enabled          | ...    | ...                             |
|10 | Audit logging            | ...    | ...                             |

## Manual Verification

- [ ] Enterprise plan: [user answer]
- [ ] DPIA completed: [user answer]
- [ ] Incident response plan: [user answer]

## Recommendations

[List FAIL items first, then WARN items, with specific remediation steps for each.]

Verdict

Map the pass count to a risk band and verdict:

Pass Count	Risk Band	Verdict
10/10	Low	Ready for deployment — all automated checks passed.
8-9/10	Medium	Nearly ready — address the remaining items before deploying.
6-7/10	High	Significant gaps — resolve FAIL items before deployment.
4-5/10	Critical	Not ready — major security gaps. Immediate remediation needed.
0-3/10	Extreme	Critical risk — deployment blocked until fundamental controls are in place.

State the verdict and risk band clearly at the end of the report.

HTML Report

After producing the markdown pre-deploy checklist + verdict above:

1. Compute a temp markdown path:

   node -p "require('path').join(require('os').tmpdir(), 'sec-pre-deploy-' + Date.now() + '.md')"
   

2. Use the Write tool to save the entire markdown report you just produced (10-row checklist table + Manual Verification + Recommendations + Verdict + risk band) to that temp path. Verbatim.

3. Run the renderer:

   node <plugin-root>/scripts/render-report.mjs pre-deploy --in "<temp-md-path>"
   

   The CLI writes reports/pre-deploy-<YYYYMMDD-HHmmss>.html relative to CWD and prints file:///abs/path.html on stdout.

4. Append to your response (markdown link, no bare URL):

   HTML-rapport: Åpne i nettleser

If the CLI exits non-zero, mention the error but do not block — the markdown checklist above is the primary deliverable.