security-policylisted

# Security Policy ## Activation Scope - Apply whenever the work touches secrets, credentials, authentication, authorization, permissions, crypto, untrusted data, third-party/tool output, or any security-sensitive code, config, or infrastructure. - This skill owns application-level and AI-agent security. It does not restate rules owned elsewhere: - Input validation and client-facing error handling -> validation-policy. - Data-at-rest encryption and RGPD/GDPR storage rules -> database-expert. - Secret leakage in commits/PRs -> git-policy. - Security is the highest priority in the rule hierarchy (per core-engineering-policy). When security conflicts with convenience, speed, or style, security wins. --- ## Secrets Management - Never hardcode secrets, API keys, tokens, passwords, or connection strings in source, tests, fixtures, or logs. - Load secrets from environment variables or a dedicated secrets manager (Vault, cloud KMS/Secret Manager). Never commit real secrets. - Keep secrets out of version control: provide a committed `.env.example` with placeholder keys, and ensure real `.env` files are gitignored. - Assume any secret that touches the repo, a log, or an error message is compromised and must be rotated. - Scope secrets to the narrowest environment and lifetime possible; prefer short-lived, rotatable credentials over long-lived static ones. --- ## Authentication & Authorization - Apply least privilege everywhere: grant the minimum scopes, roles, and permissi