Put a human signature between your pipeline and production.

Call INTYGA directly before the command that changes production. The pipeline has its own service identity and requests; the human is the approver. The two are different identities on purpose — separation of duties is a property of the key material, not of a job name.

1. Construct the target, action type, and exact parameters your pipeline will execute.
2. Request a human approval and wait for the signed result.
3. Re-verify that result locally against approver keys your pipeline already trusts, then execute once.

Step three is the one that matters. The receipt is checked in your runner, against parameters your runner derived and public keys your runner already trusted — not against anything the response claims about itself. If the plan, the workspace or the commit changed between the request and the apply, the recomputed payload no longer matches the signed bytes and the job fails instead of deploying.

The INTYGA credential in your CI secrets is a requester credential. Harvesting it lets an attacker ask for an approval. It does not let them grant one, and it does not produce a receipt that verifies.

The intyga CLI ships inside @intyga/sdk and splits the flow into three steps, so a headless runner never blocks on a browser it cannot open. Create the challenge, notify the approver where they already are, then block on the signature and verify the receipt.

1. authorize --no-wait creates the challenge and returns the nonce and approval deep-link immediately — written to $GITHUB_OUTPUT for the next step.
2. notify posts an interactive Approve button to Slack or Teams. The message carries a link, never the action parameters.
3. await --consume blocks until it is signed, verifies the receipt, and redeems the approval single-use. A non-zero exit fails the job, so every needs:-dependent deploy step is skipped.

A prebuilt require-approval GitHub Action that wraps these three steps is designed but not yet published — the CLI step below is what it will wrap, and what to use today.

Not text the pipeline wrote into a chat message. The notification carries an opaque reference and a kind — no commit message, no parameters, no PII. The approver's browser fetches the authoritative action from the gateway over TLS and displays the parameters key by key. Those canonical bytes are what the passkey signs.

This is what makes the signature mean something specific. A pipeline cannot describe a production apply as a staging one in the notification and have the human sign the description — the human signs the fetched payload, and your runner recomputes that same payload from what it is about to execute.

Broken: credential-only deployment

Possession of a CI token, a cloud role, or the whole runner filesystem stops being sufficient authority to change production. An attacker with all of it can raise an approval request; the request then sits in front of a person, and expires or is denied unless someone signs it with an enrolled authenticator. Replay is broken too: the approval binds target, action type and parameters, so a signature for a staging apply cannot be spent on production, and a redeemed approval cannot be spent twice.

Not broken: a bad change that a human approves

The gate proves a person decided. It does not read the diff, evaluate the Terraform plan, or know whether the migration is safe. Keep code review, plan review and staged rollouts — this composes with them. And gate deliberately: an approver who is asked forty times a day stops reading, which is the failure mode this control exists to avoid.