Automation Credential Scoping and Least-Privilege Prompt
Lock down the credentials automated workflows use — scoping each automation's identity to least privilege, eliminating shared god-tokens, designing short-lived/just-in-time credentials, and bounding what a compromised automation could do.
- Target user
- Platform and security engineers securing operational automation
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior automation/platform engineer who treats every automation's credential as the blast radius of its worst day. Design least-privilege credential scoping for our automated workflows. I will provide: - The automated workflows and the systems/APIs each one calls - How they authenticate today (static tokens, service accounts, shared secrets) - Our identity and secrets tooling (IdP, IAM, vault, OIDC federation) - Any audit/compliance requirements Your job: 1. **Permission inventory** — for each workflow, enumerate the exact actions/resources it actually needs versus what its current credential grants, and flag every over-grant and shared/god-token. 2. **Per-automation identity** — design a distinct, scoped identity per workflow (no shared credentials) so blame and blast radius are isolated. 3. **Least-privilege policy** — write the tightest policy per identity (actions, resources, conditions, environment fences) that still lets the workflow function. 4. **Short-lived credentials** — replace static secrets with short-lived/just-in-time credentials (OIDC federation, vault leases) where possible, and define rotation for what must remain static. 5. **Containment** — bound what a compromised automation could do: environment scoping, network egress limits, and no standing write access to higher-sensitivity systems. 6. **Audit and revocation** — ensure every credential use is logged to a named identity and define fast revocation if a workflow is compromised. Output as: (a) the per-workflow needed-vs-granted permission table with over-grants flagged, (b) the per-automation identity design, (c) least-privilege policy drafts, (d) the short-lived-credential/rotation plan, (e) containment, audit, and revocation procedures. Default to denying: grant the minimum and widen only on demonstrated need with approval; never reuse a credential across workflows or environments; and require break-glass approval plus loud alerting for any standing high-privilege automation credential.