Security policies, authentication patterns, and secret management for <repo_name>.

Agents read this before building anything that touches auth, user data, or external APIs. Security mistakes are the hardest to undo.

1. Defense in depth — Never rely on a single security control
2. Least privilege — Grant minimum necessary access
3. Secure by default — New features should be locked down; explicitly open access
4. Fail closed — When in doubt, deny access

<auth_approach> (e.g. session-based, JWT, OAuth2, API tokens)

• Library/framework: <auth_library> (e.g. Devise, NextAuth, Passport, custom)
• Session storage: <session_store> (e.g. cookie, database, Redis)
• Token format: <token_format> (e.g. signed cookies, JWT, opaque tokens)
• Multi-factor: <mfa_status> (e.g. supported via TOTP, not yet implemented)

• Session timeout: <timeout>
• Remember me: <approach>
• Concurrent sessions: <policy> (e.g. allowed, one-at-a-time)

<authz_approach> (e.g. policy-based, RBAC, ABAC)

• Library: <authz_library> (e.g. Pundit, CanCanCan, CASL, custom middleware)
• Policy location: <policy_dir>

• Every controller action must check authorization — no exceptions
• Scope all queries by tenant — never allow cross-tenant data access
• Default deny — if no policy exists, access is denied

• Development: <dev_secrets> (e.g. .env file, Rails credentials, local vault)
• CI: <ci_secrets> (e.g. GitHub Secrets, environment variables)
• Production: <prod_secrets> (e.g. environment variables, AWS SSM, Vault)

• Never commit secrets — not in code, not in config, not in comments
• Never log secrets — mask sensitive values in log output
• Rotate compromised secrets immediately — don't wait for the next deploy
• Use environment variables for runtime secrets, not config files

• Log access to sensitive data (audit trail)
• Minimize PII in logs — never log full names, emails, or IDs together
• Anonymize data in non-production environments
• Support data deletion requests (GDPR, CCPA)

• Validate all input at the boundary — controllers, API handlers, form processors
• Whitelist, don't blacklist — define what's allowed, reject everything else
• Validate type, length, format, and range
• Sanitize output — escape HTML, parameterize SQL, encode URLs

All API endpoints require authentication:

Authorization: Bearer <token>

• <rate_limit_approach> (e.g. Rack::Attack, express-rate-limit, API gateway)
• Limits: <limits> (e.g. 100 req/min per user, 1000 req/min per IP)

• Allowed origins: <origins>
• Credentials: <yes_or_no>

• Audit regularly: <audit_command> (e.g. npm audit, bundle audit, pip audit)
• Pin major versions — avoid surprise breaking changes
• Review new dependencies — check maintenance status, download count, known vulnerabilities
• Automated scanning: <scanning_tool> (e.g. Dependabot, Snyk, Renovate)

If you discover a security vulnerability:

1. Do NOT open a public issue
2. Email <security_email> or use <reporting_mechanism>
3. Include: description, reproduction steps, potential impact
4. We aim to respond within <response_time>

1. Fill in auth/authz implementation details — agents need to know which libraries to use
2. List all required environment variables — missing secrets cause confusing failures
3. Document rate limits and CORS — these are common sources of "it works locally but not in production"
4. Add real code examples for your framework's auth patterns