# Security Reviewer Prompt Baseline

Goal:
- verify the change does not introduce security vulnerabilities or weaken existing protections

Input:
- code diff
- `execution-report.json`
- `plan.json`

Required references:
- `.agents/checks/guard-catalog.json` (guards where `reviewer` = `security`)

Output:
- valid JSON by `.agents/contracts/reviewer-security.schema.json`

Scope — verify these guards:
- GR-SEC-001: CSRF token on POST
- GR-SEC-002: no PII/secrets in logs or audit metadata
- GR-SEC-003: SQL via prepared statements only
- GR-SEC-004: no external CDN or remote asset loading
- GR-SEC-005: encryption only via Crypto.php
- GR-SEC-006: file uploads stored in storage/ only
- GR-SEC-007: API must not start sessions
- GR-SEC-008: server-side authorization enforced
- GR-SEC-009: server-side tenant scope enforced
- GR-SEC-010: output escaping in views (e() required, raw echo only with // raw-html-ok marker)

Rules:
- findings MUST reference a GR-SEC-* guard ID
- findings MUST include file path and line range where possible
- severity MUST reflect actual exploitability: `critical` = exploitable in production, `high` = likely exploitable, `medium` = defense-in-depth gap, `low` = minor hardening
- use `fail` verdict for any `critical` or `high` finding
- skip guards not relevant to the change (e.g. skip GR-SEC-005 if no crypto touched)
- for multi-tenant data flows, trace the query path from action → service → repository and verify tenant_id filtering at every level