Safe security automation has a narrow scope, least privilege credentials, rate and volume caps, human approval for irreversible actions, a kill switch, and an audit trail. Check each item below before enabling a job that creates tickets, posts alerts, labels pull requests or changes code.
Definitions
Guardrail: a limit built into the automation that holds even when the logic is wrong. Blast radius: how much can go wrong if one run misbehaves. Idempotent: safe to run twice with the same result.
The checklist
Access
- Each automation has its own service identity, not a person's login. See personal login or service account.
- Token permissions are set explicitly and minimal. See least privilege token permissions.
- Secrets live in a secret store and in the narrowest scope. Third party actions touching them are pinned, see pinning to a commit SHA.
Input
- Every outside value, such as titles, branch names and webhook payloads, is treated as untrusted and passed through environment variables. See script injection.
- Webhook senders are authenticated, for example by verifying a signature. See how to verify a webhook signature with HMAC.
Volume
- A cap on tickets, messages and pull requests per run.
- Retries that honour Retry-After and stop after a few attempts. See handling HTTP 429.
- A concurrency group so runs do not overlap. See concurrency.
- Work is idempotent, with a stable key per finding. See search before you create.
Control
- A kill switch anyone on call can flip. See adding a kill switch.
- Human approval before irreversible or production changing steps. See required approval with environments.
- Timeouts and a defined failure behavior. See timeouts and failure behavior.
Evidence
- Every action is logged: what ran, on which item, with which result, and who approved. Label automation created objects so they can be filtered.
- A test plan: run in report only mode on one repository first, then widen. See shadow mode.
How to use the list
Score each automation out of 14 and write down the gaps with an owner and a date. Anything that writes to production or to many repositories should meet all 14 before it runs unattended. A read only report job can reasonably skip items 6, 11 and 14.
Review rhythm
Revisit quarterly. Permissions creep, thresholds drift and people leave. A short review of workflow files, variables and service accounts finds most problems. For the reporting side, see alert ownership maps.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a gate decides and notice where a human could still step in.
Safeguard provides policies, gates and guardrails, and its autonomous remediation is off by default with every category on Manual. Try the free scan at gold.safeguard.sh/scan.
Quick check
Do read only jobs need all of these?
No. Focus on access, input handling and failure behavior. Approval gates matter for jobs that change things.
What is the first guardrail to add?
A cap on volume per run, together with a kill switch. They limit the damage of nearly every bug.
Last reviewed: 19 October 2026.
