Production databases
Bind the cluster, database, table, query class, and environment before a destructive operation can proceed.
Production operations
Keep administrative escape hatches human-approved.
Gate the rare operation that has disproportionate blast radius: a database wipe, a production scale change, a credential rotation, or a bulk export. These are the actions that break glass by design — performed under pressure, by whoever holds the credential, usually with no second pair of eyes and no record beyond a shell history file.
The integration point
Put the gate inside the tool that performs the operation — the runbook script, the internal admin endpoint, the operator CLI — not in a wiki page that says to ask first. The tool constructs exactly what it is about to do, requests an approval, verifies the receipt locally, and only then executes.
- Name the target: the cluster, account or environment that will run the operation.
- Construct the parameters the command will actually use — not a summary of them.
- Request an approval and wait for the signed result.
- Re-verify the receipt against those same parameters and keys you already trust, then run once.
Verification happens in your process. If the operator edits the command after approval, the recomputed payload no longer matches the signed bytes and the tool refuses — without asking us anything.
const action = {
target: "prod-eu-1", // this cluster — no replay against staging
actionType: "truncate_table",
params: { database: "orders", table: "events", rows: 41_882_113 },
};
const approval = await intyga.requireApproval(
"Truncate orders.events (41.8M rows) on prod-eu-1", action);
if (approval.status !== "APPROVED") throw new Error("not approved");
// nonce and approvers come from YOUR side — a receipt cannot vouch for its own signer.
const check = verifyApprovalReceipt(approval.receipt!, {
...action, nonce: approval.nonce!, approvers: TRUSTED_APPROVERS,
}, {
expectedOrigin: process.env.INTYGA_WEBAUTHN_ORIGIN!,
expectedRpId: process.env.INTYGA_WEBAUTHN_RP_ID!,
});
if (!check.ok) throw new Error("receipt mismatch: " + check.reason);
await runTruncate();
// Or with no application code at all, from a runbook script:
// npx @intyga/sdk authorize "Rotate aws-prod credentials" \
// --gateway "$INTYGA_GATEWAY_URL" --target prod-eu-1 \
// --type rotate_credentials \
// --params '{"service":"aws-prod","environment":"production"}' \
// --consumeUse the action as the policy boundary
Kubernetes and cloud overrides
Make scale, rollout, ingress, IAM, and failover changes wait for a signed decision.
Secrets and credentials
Apply four-eyes to high-impact rotations so the requester cannot silently approve their own change.
Bulk exports and data access
Exfiltration does not look destructive. A full-table dump or a customer-data export deserves the same signature a delete does.
Break-glass elevation
The moment someone assumes the emergency role is the moment worth binding to a person, a reason, and a time — not the actions taken afterwards.
Backup and retention changes
Disabling a backup job or shortening retention is the quiet precursor to an incident nobody can recover from.
What the human actually approves
Those canonical bytes are what the passkey signs. Your executor reconstructs them from its own intended parameters before it runs.
The approver does not receive the parameters in a notification. The push carries an opaque reference and a kind only — no hostnames, no table names, no customer data. The approver's browser fetches the authoritative item from the gateway over TLS and displays it key by key, which is what makes “I saw what I signed” a technical statement rather than a hope.
{
"target": "prod-eu-1",
"actionType": "rotate_credentials",
"display": "Rotate aws-prod credentials",
"params": { "service": "aws-prod", "environment": "production" },
"nonce": "single-use challenge",
"expiresAt": "short approval window"
}Governance the operator cannot lower
Quorum, four-eyes and hardware-key class are server-side approval rules, evaluated by the gateway and frozen onto the challenge when it is created. There is no quorum argument on the wire, so the tool requesting the operation cannot ask for a weaker requirement, and neither can whoever compromised it.
The caller supplies an action ID, which the gateway matches exactly. Each specific rule must preserve the tenant baseline. New workspaces deny unknown IDs unless an administrator explicitly chooses baseline approval. Older workspaces retain their recorded semantics until signed activation. See approval rules.
- M-of-N quorum — two SREs for a truncate, three for a region failover, expressed once and enforced wherever the action is raised.
- Four-eyes — the requester is excluded from approving, so nobody ratifies their own rotation.
- Hardware-key class — device-bound authenticators only, optionally narrowed by AAGUID to your corporate security-key fleet. Synced passkeys are rejected.
- Approver groups, snapshotted — eligibility is captured at challenge creation, so an on-call rota edit cannot change who may sign an in-flight operation.
- Escalation — a pending operation re-notifies a wider group after a timeout. It adds approvers; it never lowers the quorum or extends the expiry.
Hardware-class and attestation constraints are checked at signing time, not only when the request is raised — so an approver cannot unknowingly ratify an operation requested by an unattested workload holding a leaked key.
The 3 a.m. question: what happens when INTYGA is down?
Approvals fail closed, so we are a dependency in the path of every operation you gate. For production operations specifically, that deserves an answer rather than reassurance.
Offline Approval
Your relying party generates the nonce and builds the challenge itself. Approvers review and sign it on a disconnected device. Your runtime verifies the result through the same procedure it always runs. INTYGA is not in the loop at any point, and the validity window is bounded in minutes — implementations cap it at 60 — so a proof minted with an over-long expiry is rejected even when its signature is valid.
What that costs you
It is a procedure you operate, not a switch we flip: write the runbook, rehearse it, and confirm your approvers can actually reach a signing device on a bad day. The SDK returns it as a distinct OFFLINE_APPROVED status rather than APPROVED, so enabling the fallback has to be a conscious change at each call site instead of a quiet global loosening.
What this breaks, and what it does not
Broken: sole possession as authority
Holding the cluster credential, the admin session, or the operator's laptop stops being enough to perform the gated operation. An attacker with all of it raises a request that surfaces to other people as its real parameters and expires unsigned. Replay is broken too: the signature binds the target and the exact arguments, so an approval for a staging truncate cannot be spent on production, and a redeemed approval cannot be spent twice.
Not broken: a genuinely bad call
If the operation is wrong and two engineers approve it anyway, it runs. The gate proves a named person decided over exact parameters; it does not know that failing over the wrong region at peak is a mistake. Keep runbooks, dry runs and reversible defaults — this composes with them and makes the after-action record unambiguous.
What the incident review gets
A receipt, not a shell history
Each approval is signed over the canonical payload — target, operation, parameters, nonce, time — by an identified human's authenticator.
Checkable by someone who distrusts us
Recompute the payload from your own records and verify the signature with @intyga/verify. Open source, minimal dependencies, no INTYGA secret.
Tamper-evident ordering
Approvals, denials and rule changes append to a hash-linked ledger with periodic checkpoints, so committed entries cannot be quietly rewritten after the fact.
Precisely scoped: the log proves committed entries were not altered. It cannot prove an event was never withheld from commitment. See the security architecture for how the chain is anchored.
This pattern extends beyond operations
The same primitive sits in front of deployments and Terraform applies, package releases, payments and treasury movements, and AI agent tool calls. Wherever a machine performs an irreversible action on someone's behalf, possession of a credential stops being sufficient authority.
Do not replace native controls—compose with them.
Continue using IAM, branch protections, and platform-native approval gates. INTYGA adds a portable, per-action signature and a receipt that can be verified outside the platform. Approvals are not metered, so the Developer tier gates as many actions as you run, at no cost — what the paid tiers add is seats, a longer evidence-retention window, and quorum rules.
Read “Signing the Letter, Not the Envelope” →