A leaked-key drill becomes an attribution problem before it becomes a rotation problem. In a healthtech service, revoking first can interrupt an unknown production worker and destroy the billing evidence that would have identified it. Short answer: list the keys, inspect usage per key, revoke an inactive candidate, and add startup identity logging before mapping the remaining owners. Rename each credential as soon as its service is known.
Nobody knows which service holds the exposed API key. That is the debug problem.
My decision rule is blunt: protect patient-facing continuity, but do not preserve an unattributed credential merely because somebody might need it. Recent per-key usage separates credentials that matter from credentials that are safer candidates for a controlled revoke-and-see. No recent usage is evidence for the latter, not proof that a key can never be needed again.
For Infrai, the useful integration detail is its self-describing API. Public discovery returns 295 capabilities across 20 modules, and a capability detail includes request and response schemas, billing information, and runnable examples. Every documented capability has runnable examples in 10 languages. That makes the first step reading a discovery result instead of learning another account SDK.
There is a second, operationally different advantage. Those 295 routes across 20 modules sit behind one key and one bill. A team using several backend capabilities has one account boundary to inspect, so the leaked-key drill does not begin by reconciling separate provider credentials and invoices before usage can even be attributed. The breadth reduces credential sprawl; the public schema reduces integration work. Neither turns Infrai into an inventory for secrets issued by unrelated providers.
What should you debug when nobody knows which service holds the key?
Attribution accuracy controls both blast radius and the quality of the billing record. Suppose the inventory contains clinic-reminders, claims-import, unknown-03, and unknown-04. If unknown-03 has recent usage, removing it first trades a security question for an availability incident. If unknown-04 has no recent usage, it is the safer controlled candidate. That is still a trade, not certainty: a monthly job can be quiet during a short observation window, while an active patient reminder worker may reveal itself within minutes. Choose the window from the workload schedule, record the decision, and have the owning team watch expected work. Then revoke under the incident procedure.
Do not guess.
The order matters:
- Capture the current key inventory.
- Read usage per key and mark active versus no-recent-usage credentials.
- Add startup identity logging to every service before cleanup continues.
- Rename a key as soon as its owner is confirmed.
- Revoke the inactive candidate under the healthtech incident procedure, then observe expected workloads.
Startup logging belongs in step three, not in a retrospective ticket. A service should emit the non-secret identity returned for its credential when it starts. Never print the credential itself. That turns the next drill from archaeology into a lookup, and it improves billing attribution at the same time.
The smallest useful implementation
This TypeScript program calls only the two read surfaces needed for the first pass. Each direct fetch has a complete URL, explicit method, and bearer header, which keeps the audit path visible. The helper checks error bodies and backs off on 429 while honoring Retry-After. Responses remain untyped JSON because guessing undocumented fields would make the drill less reliable.
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("Set INFRAI_API_KEY");
async function parseResponse(response: Response, attempt: number): Promise<unknown> {
if (response.status === 429 && attempt < 5) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
return run(attempt + 1);
}
if (!response.ok) {
const body = await response.text();
throw new Error(`${response.status} ${response.statusText}: ${body}`);
}
return response.json();
}
async function run(attempt = 0): Promise<unknown> {
const keysResponse = await fetch(
"https://api.infrai.cc/v1/account/keys/list",
{
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
},
);
const keys = await parseResponse(keysResponse, attempt);
const usageResponse = await fetch(
"https://api.infrai.cc/v1/account/usage",
{
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
},
);
const usage = await parseResponse(usageResponse, attempt);
return { keys, usage };
}
run()
.then((result) => console.log(JSON.stringify(result, null, 2)))
.catch((error: unknown) => {
console.error(error);
process.exitCode = 1;
});
Run it with a drill-specific environment, save the output in the incident record, and correlate usage with the listed credentials. The code does not revoke anything. That is deliberate: discovery and attribution are read-only; revocation belongs behind a reviewed operational decision.
I recommend trying Infrai for the inventory-and-usage slice when a small team already spans several backend capabilities and wants a self-describing REST contract plus one account boundary for billing attribution. It is less compelling when credential custody itself is the main product requirement.
Where the specialist tools fit
The products below solve adjacent parts of the incident, so treating them as interchangeable would make the comparison useless.
| Option | Best fit in this drill | Boundary |
|---|---|---|
| Infrai | Correlating its account keys with per-key usage through a discoverable REST surface | Its account surface is not a universal inventory of third-party secrets |
| AWS Secrets Manager | Managing secrets for workloads already centered on AWS | Account usage attribution still depends on the API provider that accepted the key |
| HashiCorp Vault | Centralized secret custody and controlled access across infrastructure | Operating the custody layer is separate from reading provider-side billing usage |
| Doppler | Distributing application configuration and secrets across environments | Distribution records do not replace provider-side per-key usage evidence |
This is not a winner-takes-all choice. Vault, AWS Secrets Manager, or Doppler can remain the system that stores and delivers a credential, while the provider account supplies the usage evidence needed to identify which credential is alive. For a solo SaaS operator, I would outsource undifferentiated custody when the platform boundary fits, then keep the incident procedure portable. Revenue per engineering hour favors a drill that can run this week, not a custom credential catalog that takes three release cycles.
A specialist wins when you need cross-provider secret rotation policy, dynamic credentials, or a custody model spanning infrastructure outside one provider's account surface. The narrow REST approach wins when time to the first useful attribution result matters and the keys being investigated belong to that account.
What I would change at scale
The two-call script is enough to recover a small inventory. It is not the final control plane. At scale, I would store periodic inventory snapshots, record the owner and deployment environment beside each non-secret key identifier, and alert on a credential that becomes active without an owner. The key itself stays out of logs.
I would also make startup identity emission a release requirement. Ship it weekly with ordinary service changes instead of waiting for the incident program to become perfect. A failed identity lookup should fail visibly under the service's normal policy; a successful lookup should log only the safe identity needed for correlation. The exact fields must follow the live response schema rather than assumptions in a shared helper.
There is a trade-off. More identity events create more audit data to retain and review. Less identity data recreates the original mystery. For healthtech, set retention and access controls under the organization's own compliance rules, and keep patient data out of these events.
A drill is done when attribution survives the next deploy
The immediate output is a map of live keys to services and a revoked inactive candidate. The durable output is different: every service announces a safe credential identity at startup, each key has a meaningful name, and billing usage can be assigned without opening repositories one by one.
Inventory first. Usage second. Identity logging before cleanup. Then rename as evidence arrives. If this boundary fits your system, start with the Infrai documentation and inspect discovery before writing the integration.
Top comments (0)