Secrets Identity Hardener

---
name: secrets-identity-hardener
description: MANUAL-ONLY; never auto-invoke. Harden how an application handles secrets and identity — move hardcoded credentials/tokens/keys into a secret manager or server-only env, classify each variable as public vs server-only (and catch client-bundle exposure like VITE_/NEXT_PUBLIC_ leaks), enforce least-privilege service accounts, add rotation and revocation, and tighten session/token handling (expiry, refresh, storage flags) — with tests proving a secret is unreachable from the client and a rotated credential is honored. Use when secrets are hardcoded/committed, env classification is unclear, a key needs rotation, or service accounts are over-privileged. Side-effecting and manual-only. Do NOT use to implement one app-layer control (appsec-implementer), audit RLS/service-role in the DB (rls-policy-auditor), or model threats (threat-modeler).
disable-model-invocation: true
---

# Secrets & Identity Hardener

Terms: **CI** means continuous integration and **CI/CD** continuous
integration and continuous delivery; **IaC** means infrastructure as code;
**KMS** means key management service; **RLS** means row-level security; and
**authz** is short for authorization.

## Purpose

Move an application from "secrets are wherever they landed" to a defensible
posture: every secret lives in a secret manager or server-only environment,
every environment variable is classified public vs server-only, client bundles
provably contain no server secret, service accounts hold least privilege, and
credentials rotate and can be revoked. The deliverable is a scoped set of code/
config changes plus evidence — a test or build check proving the secret is not
in the client bundle, and that a rotated credential is honored — not a promise.
This skill changes code and config, so it is manual-only and gates production
changes through human approval.

## Use When

- Use when: secrets are hardcoded in source, committed to the repo, or present
  in the client bundle.
- Use when: environment-variable classification is unclear — which vars are
  safe to ship to the browser, which are server-only, CI-only, or deploy-only.
- Use when: a credential must be rotated or revoked, or a service account is
  over-privileged.
- Use when: session/token handling needs tightening (expiry, refresh,
  storage flags, revocation).
- Do NOT use when: the task is one specific app-layer control (validation,
  encoding, an authz check) — that is `appsec-implementer` *(manual-only)*.
- Do NOT use when: the concern is database service-role/RLS leakage — that is
  `rls-policy-auditor`.
- Do NOT use when: you are enumerating threats or deciding what to protect —
  `threat-modeler`.
- Do NOT use when: only asked to REVIEW a diff for secret leaks — that is
  `security-pr-reviewer`; this skill remediates.

## Inputs to Inspect

1. Where secrets currently live: source files, committed `.env`, config,
   CI/CD variables, IaC, container images. Find them before moving them.
2. The client build config: bundler env-exposure rules (`VITE_`,
   `NEXT_PUBLIC_`, `REACT_APP_`, etc.) and what actually ends up in the
   shipped bundle. A prefix convention is not proof — inspect the build output.
3. The secret manager / platform available (cloud secret store, KMS, vault,
   deployment secrets) and how the app loads from it at runtime.
4. Service accounts and their grants: what each machine identity can do vs
   what it needs (least privilege).
5. Session/token handling: token type, storage (cookie vs localStorage),
   flags, expiry, refresh, revocation path.
6. Git history for committed secrets (a rotated secret is safe; a
   still-valid committed secret needs rotation, not just deletion).

## Workflow

1. **Inventory and classify.** List every secret and env var; classify each:
   public (safe for client), server-only, CI-only, deploy-only. Anything
   server-only currently reachable by the client is a finding to fix.
2. **Classify the change** (`change-classification-gate`); rotating live
   credentials, editing production config, or touching deploy secrets crosses
   `human-approval-boundary` — check the complete effective approval record
   for an applicable active grant and obtain any missing scope before those
   steps.
3. **Write the proving check first** where feasible: a test or build assertion
   that the server-only secret does NOT appear in the client bundle / is not
   readable from the browser. Confirm it FAILS against the current exposed
   state (the leak is real) before fixing.
4. **Remediate storage:** move hardcoded/committed secrets into the secret
   manager or server-only env; load at runtime server-side; replace client
   references to server secrets with a server-side proxy/endpoint.
5. **Rotate what leaked.** A secret that was committed or client-exposed is
   compromised — rotate it under an applicable grant, don't just relocate it. Deleting
   it from source without rotation leaves a live credential in git history.
6. **Least-privilege service accounts:** narrow grants to what's needed;
   record what was removed and why.
7. **Tighten sessions/tokens** if in scope: `HttpOnly`/`Secure`/`SameSite`
   cookies, sane expiry, working refresh, server-side revocation; add tests.
8. **Prove it.** Rerun the bundle/exposure check to green; verify a rotated
   credential is honored and the old one rejected (where testable). Record
   real commands and output.
9. **Stage exactly the intended files** (`reviewable-diff-discipline`) and
   report: what moved, what rotated, residual exposure (e.g. history needing
   BFG Repo-Cleaner/history rewrite and rotation), and follow-ups. Never
   print the secret values themselves.

## Output Format

```
SECRETS & IDENTITY HARDENING — <app/scope>
Env classification: <var — public | server-only | CI-only | deploy-only>
Exposed secrets found: <name/location — how exposed> (values NOT printed)
Change class: <class> — approval: <path / obtained?>
Bundle-exposure check (red→green): <cmd> — before: FAIL, after: PASS
Remediation: <secret — moved to <store>, loaded <how>, client uses <proxy>>
Rotations: <credential — rotated? (approval) | rotation still required>
Service accounts: <identity — grants removed → least privilege>
Session/token changes: <flags/expiry/revocation added + tests>
Residual risk: <git history, secrets not yet rotated, out-of-scope stores>
Files changed: <exact paths>
Handoff: security-pr-reviewer to verify; ops to complete rotations if pending.
```

## Validation Checklist

- [ ] Every secret and env var classified; client-reachable server secrets
      identified.
- [ ] Client bundle inspected (not just prefix convention) and a check proves
      no server secret ships to the browser.
- [ ] Committed/exposed secrets are ROTATED, not merely deleted from source.
- [ ] Service accounts reduced to least privilege with removals recorded.
- [ ] Session/token hardening (if in scope) has flags, expiry, revocation,
      and tests.
- [ ] Proving checks run red before and green after; real output recorded.
- [ ] No secret values printed in output, logs, or tests.
- [ ] Staged set equals the intended footprint; production changes approved.

## Security Rules

- A secret that was ever committed or shipped to a client is compromised and
  must be rotated — relocation alone does not restore secrecy.
- Server-only secrets must be provably absent from the client bundle; a
  naming convention (`VITE_`/`NEXT_PUBLIC_`) is a rule, not evidence — verify
  the built artifact.
- Never print, log, echo, or commit secret VALUES; operate on names and
  locations. Tests assert on absence/behavior, not on the secret's content.
- Rotating live credentials, editing production config, or changing deploy
  secrets requires applicable explicit human authority
  (`human-approval-boundary`); an effective standing grant may supply it.
- Least privilege is the default for machine identities; broad grants require
  written justification.

## Gotchas

- Deleting a hardcoded key from source but not rotating it leaves it live in
  git history — the fix is rotation, and history rewrite is a separate,
  approval-gated action.
- Bundler prefix rules are opt-in exposure: a var without the public prefix is
  hidden, but a server secret accidentally given the prefix ships to every
  browser — inspect the bundle.
- Moving a secret to an env var that the frontend build still inlines just
  relocates the leak; confirm the runtime read is server-side.
- Rotating a shared credential can break other consumers — enumerate who uses
  it before rotating, and coordinate; this is why rotation is approval-gated.
- localStorage-stored tokens are readable by cross-site scripting (XSS);
  moving to HttpOnly cookies changes cross-site request forgery (CSRF)
  posture — harden both together, not one in isolation.

## Stop Conditions

- Rotating a live credential, editing production config, or rewriting git
  history to purge a secret → stop unless the action is covered by an
  applicable active human grant; obtain any missing scope through
  `human-approval-boundary`. These are irreversible or broadly impactful.
- The only safe fix requires an ops action outside the repo (rotate a cloud
  key, revoke a token in a provider console) → stop and hand off with exact
  steps; do not fake completion.
- A secret is exposed in a way that is actively exploitable in production →
  report immediately; containment/rotation priority is the human's call.
- The task expands into database service-role/RLS scope → hand to
  `rls-policy-auditor`; into a single app control → `appsec-implementer` *(manual-only)*.

## Supporting Files

- [references/secret-classification-and-rotation.md](references/secret-classification-and-rotation.md)
  — the env-classification rubric, client-bundle exposure checks per bundler,
  rotation procedure, and least-privilege service-account patterns.
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination against `appsec-implementer`,
  `threat-modeler`, and `security-pr-reviewer`.