# Security Guidelines

## Mandatory Security Checks

Before declaring security-sensitive work complete or committing it:

- [ ] No hardcoded secrets, credentials, or tokens
- [ ] External and user inputs are validated
- [ ] Database queries use parameterization
- [ ] Untrusted HTML is sanitized or safely escaped
- [ ] Authentication and authorization checks are enforced server-side
- [ ] State-changing browser requests have appropriate CSRF defenses
- [ ] Public endpoints have appropriate abuse and rate controls
- [ ] Errors and logs do not leak sensitive data
- [ ] File paths and shell arguments cannot enable traversal or injection

Apply controls according to the actual threat model; do not add irrelevant mechanisms merely to satisfy a checklist.

## Secret Management

- Never hardcode secrets in source code or examples.
- Use environment variables or an approved secret manager.
- Validate required configuration at startup without printing secret values.
- If a secret may have been exposed, stop, notify the user, rotate it, and inspect history for similar exposure.

## Pi Trust and Extensions

Pi extensions and packages execute with the user's full system permissions. Review their source before installation, and trust project-local `.pi/` resources only for repositories you trust. Prefer restricted tool sets or a container for untrusted code; Pi core has no built-in permission popup.

## Security Response Protocol

When a vulnerability is found:

1. Stop unrelated work that could worsen exposure.
2. Determine severity, affected data, and reachable attack surface.
3. Load an available security skill or use an extension-provided reviewer when present; otherwise perform the audit directly.
4. Fix critical issues before continuing.
5. Rotate exposed credentials and review the codebase for the same pattern.
6. Add a regression test and report remaining risk.

Do not assume a specialist security agent is built into Pi.