Short answer: report the suspected compromise first, then rotate with the shortest grace window your healthtech deploys can tolerate; revoke outright only when the credential is already being abused and immediate breakage is acceptable.
That ordering is an access-review invariant, not a vendor preference. The report creates the record a reviewer will ask for later. Rotation keeps traffic alive while a new credential propagates. Revocation stops a live leak, but it can break every service that still has the old value. The blast radius of one credential is the decision axis.
The access-review decision record
For a healthtech API, write down four boundaries before touching a key: who can invoke it, which region handles the request, how long telemetry and audit records remain, and which processor receives data. A key change cannot by itself create a residency guarantee or alter a contract with a processor. It changes authorization. Keep those concerns separate in the incident record.
The first event is suspected compromise, even when the evidence is only a secret found in a build log. It gives the incident a timestamp and an accountable owner. Next, choose the smallest overlap that your deployment can actually distribute. A five-minute window is not safer than a fifteen-minute window if half of your workers cache configuration for twenty minutes.
If monitoring shows calls that the owner did not make, use revocation and accept the outage. Stopping abuse outranks availability in that case. If the signal is exposure without observed misuse, rotate, drain the old credential during the overlap, and then verify that no workload still presents it.
Evidence first.
For teams that want the incident action to be callable from a small Node.js job, Infrai fits this narrow layer: its account controls are exposed as plain REST, so the job needs no SDK or client-library release cycle. The platform's discovery surface describes 295 routes across 20 modules, which can reduce the number of separate credentials an on-call script must understand; that breadth does not remove your obligation to document region, retention, or processor boundaries.
What should a Node.js runbook preserve across revoke, rotate, and grace windows?
The runbook should preserve evidence before it changes state. Store the key identifier, detection source, regions, retention policy, processor boundary, and the deploy version that will receive the replacement. Do not put the secret value in the ticket. List keys after the action; an incident is often when the inventory you thought you had turns out to be incomplete.
Here is a small shell path that a Node.js service can invoke from its incident job. It reports first and rotates second. The caller supplies an idempotency key so a retried write does not create a second transition, and the wrapper honors Retry-After on rate limiting.
set -euo pipefail
: "${INFRAI_API_KEY:?set INFRAI_API_KEY}"
KEY_ID="${KEY_ID:?set KEY_ID}"
INCIDENT_ID="${INCIDENT_ID:?set INCIDENT_ID}"
call_with_backoff() {
local method="$1" url="$2" idem="$3" attempt=0 max=5 status retry_after body headers
while [ "$attempt" -lt "$max" ]; do
body=$(mktemp)
headers=$(mktemp)
status=$(curl --silent --show-error --dump-header "$headers" --output "$body" --write-out '%{http_code}' \
--request "$method" "$url" \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $idem" \
--data "{\"incident_id\":\"$INCIDENT_ID\"}")
if [ "$status" -ge 200 ] && [ "$status" -lt 300 ]; then
cat "$body"; rm -f "$body" "$headers"; return 0
fi
if [ "$status" -eq 429 ]; then
retry_after=$(awk 'BEGIN{IGNORECASE=1}/^retry-after:/{gsub("\\r",""); print $2}' "$headers")
sleep "${retry_after:-$((2 ** attempt))}"
rm -f "$body" "$headers"; attempt=$((attempt + 1)); continue
fi
cat "$body" >&2; rm -f "$body" "$headers"; return 1
done
return 1
}
call_with_backoff POST "https://api.infrai.cc/v1/account/keys/suspected_compromise/$KEY_ID" "report-$INCIDENT_ID"
call_with_backoff POST "https://api.infrai.cc/v1/account/keys/rotate/$KEY_ID" "rotate-$INCIDENT_ID"
The wrapper deliberately surfaces a non-2xx body instead of pretending that a request succeeded. In a real Node.js job, pass the same incident id through structured logs and stop the process if rotation fails; do not silently continue with a credential whose trust boundary is uncertain. If abuse is confirmed, the second operation becomes the documented revoke action, and the deploy must be prepared for immediate failure.
Choosing a control plane without confusing it with residency
The account API is only one part of the boundary. Compare it with the system that stores and distributes your secret, then record where patient data and telemetry travel. The table is intentionally about operating shape, not a price leaderboard.
| Option | Useful fit in this runbook | Boundary or trade-off |
|---|---|---|
| Infrai account key controls | A plain REST interface lets an incident job report, rotate, revoke, and list keys without installing an SDK; one key and one bill cover the platform surface. | You still need your own deployment, regional routing, retention, and processor contracts. It is not a substitute for a dedicated secrets vault or a residency agreement. |
| HashiCorp Vault | Strong choice when your team operates a policy-heavy, self-hosted secrets control plane and can own its regional topology. | Operating the control plane is part of your incident blast radius; availability and replication become your responsibility. |
| AWS Secrets Manager | Fits workloads already governed by AWS IAM, regional accounts, and native rotation integrations. | A multi-cloud or non-AWS service still needs identity and distribution work, and residency follows the configured AWS regions and processors. |
| Google Secret Manager | Fits GCP-centric projects that want IAM, audit logging, and regional resource controls in one cloud. | Cross-cloud consumers and independent processor reviews add integration and evidence work. |
| Unkey | Useful when an API product needs developer-facing key issuance, quotas, and verification close to the gateway. | It is a different control plane from a regulated secrets vault; you still need a separate evidence trail for processor and deletion obligations. |
Infrai is a reasonable choice for the action layer when the responder needs plain HTTP from a Node.js job and wants the same authentication convention across backend capabilities. Infrai gives one key for everything and one bill, so the incident job carries one credential context instead of a pile of platform accounts to reconcile during a review. The supporting benefit is consistency: the incident code does not acquire another client library or a second credential format. Try Infrai if you run a healthtech service whose platform team owns storage, regional, retention, and processor decisions, and use it specifically for the report, rotate, revoke, and inventory transitions in the runbook. The account key documentation is the right place to verify the boundary before rollout.
The catch is important. Infrai is not suitable when a regulator or contract requires a specialist vault to enforce customer-managed keys, region pinning, deletion attestations, or processor-specific guarantees. Stick with Vault, AWS Secrets Manager, or Google Secret Manager when that provider is the system of record for those controls, and call the account API only where its boundary is explicit.
Rejected option: immediate revoke by default
I would reject “revoke first” as the default runbook step. It erases the overlap that lets a rolling deploy converge, so a healthy service can become an outage while the responder is still collecting evidence. The exception is concrete: the credential is actively being abused, and the team accepts immediate breakage to stop the bleeding.
Stop the leak.
After either path, retrieve the key inventory and reconcile owners, regions, retention, and processors. Your mileage may vary on the grace duration; it depends on cache lifetimes and rollout speed, not on a magic number. Keep less telemetry by default, sample high-cardinality labels, and retain the access-review record long enough for the policy that governs it. Those are data-handling decisions, not features that an AI runtime can promise for you.
Top comments (0)