This walkthrough takes a repository from zero to a green-or-red security check on every pull request: provision an API key, add the workflow, and pick the failure rule that matches how your team ships.
Ten minutes of setup buys a gate that runs the same probes as the platform against the endpoint your PR is about to change. The concept pages cover how the gate works; this one gets it running.
1. Provision the API key
- Open /settings/api-keys, click Create key. Name it after the repo (e.g. acme-chat-api).
- Copy the didk_ prefix exactly once — the raw value is never shown again.
- In the repo, Settings → Secrets → Actions → New repository secret. Name: DOESITDEFEND_API_KEY. Value: paste the didk_ key.
Name the key after the repo so a leaked-key incident can be traced to its source in seconds. The raw didk_ value is displayed exactly once — if it is lost, revoke and create another rather than storing a half-recorded secret.
2. Add the workflow
- Create `.github/workflows/llm-gate.yml` and use the Action path shown in the CI Integration reference.
- Set `endpoint`, `api-key`, the API format (`template`), and the failure rule (`fail-on`). These fields define what is tested and how the result affects the check.
- Open a pull request and confirm that GitHub records the check. Runtime depends on the target and selected scenarios.
The workflow file is small on purpose: endpoint, key, template, and fail-on are the whole contract. Open the first pull request and confirm the check appears in the Checks tab before trusting the gate in earnest.
3. Choose when the check fails
- Use `fail-on: regression` to fail only when the result worsens against a comparable prior run. Without a valid prior run, the first result is informational.
- Use `fail-on: findings` when any open finding must fail the check, including on the first run.
- Use `fail-on: never` while adopting the workflow so the team can inspect results without blocking changes. Operational errors remain separate from security verdicts.
Pick the strictest rule your team will tolerate, then loosen only under protest. regression is the honest default once a baseline exists; never is an adoption posture, not a destination — operational errors keep failing the build in every mode.