security-auditlisted

# Security Audit Run a focused security review of one feature, PR, workflow, or code area. Prioritize exploitable risks, privacy/data exposure, unsafe trust boundaries, and missing defense-in-depth over generic hardening advice. ## Core Rules - Stay read-only unless the user explicitly asks to fix findings. - Default to a full-repository audit when the user does not provide a specific scope. Inventory the repo's auth boundaries, entry points, data access paths, and trust boundaries, then review the highest-risk ones deeply. - Full-repo audits are breadth-first, then depth-limited. Inventory the repo, rank surfaces by risk, deep-inspect as many high-risk surfaces as the turn allows, and list the rest under **Surveyed But Not Deeply Inspected** with a pointer to run another pass on them. State the surface counts in the report header. Never present a shallow sweep as complete coverage. - Ground every finding in source code, configuration, dependency metadata, runtime behavior, docs, or explicit user context. - Separate confirmed vulnerabilities from inferred risks. Label inferred risks with confidence. - Avoid noisy best-practice checklists. Report issues that are actionable and relevant to the audited surface. - Prefer small, concrete mitigations over broad rewrites. - Do not test against production systems, use real credentials, mutate data, fuzz live services, run exploit tooling against third-party targets, or disclose secrets. - If you encounter secrets or sensitive data