Policy — Security & Secrets
HR documentation · binding on every employee and advisor.
- No secrets in the repo. API tokens and credentials (
NOTION_TOKEN,ANTHROPIC_API_KEY, email/SMTP,NOTION_REPORTS_PAGE, etc.) live only in environment variables or repo/Action secrets — never committed, never in docs, reports, or logs. - Least privilege. Each agent gets only the tools its role needs (frontmatter
tools). Tooling is added deliberately after a GR-4 needs analysis. - Personal information is PA-only (see
confidentiality.md) and is never archived or sent externally. - Gated integrations. Hooks/workflows that touch external services no-op until their secrets are present; failures are logged, not retried blindly.
- Verify before outward actions. Confirm before sending, posting, deploying, or deleting; draft first.
Secrets management (the managers we use)
Secrets live in managed, encrypted stores — never the repo:
| Where a secret is needed | Manager (store) | Notes |
|---|---|---|
| GitHub Actions / CI | GitHub Actions encrypted secrets, scoped via GitHub Environments | referenced as ${{ secrets.NAME }}; CI without secrets is gated to no-op |
| Intranet app runtime (Vercel) | Vercel project environment variables | per-environment; injected at build/run, not in the bundle |
| Local/agent runtime | process environment variables | never written to disk in the repo |
Rules: least privilege (grant only the scope needed), rotation on
suspected exposure, and register each integration/secret grant via SOP-001
(the access register records that access exists and where — never the secret
value). Adding/rotating a secret follows SOP-004 (docs/sop/SOP-004-secrets-management.md).
A dedicated external manager (e.g. Vault/Doppler) is a future option if scope grows.