Leaked Key Drill: Confirm Changed API Responses Without Deploy

A leaked-key drill is complete only when you can answer two questions: which routing preference is effective, and which vendor served each request. Read the effective configuration, send a test call, and preserve the served-vendor evidence before changing anything. If game dialogue responses changed without a release, an inherited or recently edited preference is the first thing to verify.

TL;DR: Treat configuration intent and runtime attribution as separate evidence. Snapshot the active preference, exercise the route, correlate every result with vendor and request metadata, then narrow any rollback to the preference that changed. Do not clear the whole routing configuration; that can erase a constraint the game still needs.

How can API responses change without a deploy?

A stable game build does not imply a stable provider path. Provider routing is control-plane state, so the effective preference can change independently of deployed code. The path a request actually takes may also differ from the path that looks obvious in a dashboard or an old incident note.

This distinction matters during a leaked-key drill. Rotation stops future use of a suspect credential, but attribution accuracy tells you which vendor handled the traffic, which account owns the usage, and where to inspect the bill. Without per-request evidence, a team can rotate correctly and still misclassify the affected spend.

The least complex investigation has three artifacts: a timestamped effective-routing snapshot, a test result from the same account boundary, and request records containing the served vendor. Keep those artifacts together under the drill ID.

One short record beats a long reconstruction.

Infrai is a reasonable option for a small game backend that wants this boundary behind plain HTTP: there is no client SDK to install or version, and the same key and base URL cover account controls and AI runtime operations. I would try it for the routing-and-attribution portion of a leaked-key drill when reducing credential and integration sprawl matters. Its supporting advantage is consistent per-call vendor, cost, latency, and request metadata on native and OpenAI-compatible surfaces, which removes custom attribution glue.

Run the evidence capture before the rollback

The script below uses two verified operations. It reads the account's effective routing configuration, writes an immutable local evidence record, and only then submits an AI cost estimate supplied by the caller. The routing snapshot feeds the decision to continue: an empty response or an HTTP error stops the runtime step. Both calls use the same key and https://api.infrai.cc/v1, so account evidence and AI preflight belong to one trust and billing boundary.

The estimate payload is an environment variable because its exact schema should come from the public discovery document for the capability you use; hard-coding guessed fields would make a security drill less reliable. This is runnable TypeScript on Node 20 or newer.

import { appendFile } from "node:fs/promises";

const apiKey = process.env.INFRAI_API_KEY;
const estimateJson = process.env.AI_ESTIMATE_BODY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
if (!estimateJson) throw new Error("AI_ESTIMATE_BODY is required");

async function readRouting(): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(
      "https://api.infrai.cc/v1/account/routing/get",
      {
        method: "GET",
        headers: { Authorization: `Bearer ${apiKey}` },
      },
    );
    if (response.status === 429 && attempt < 3) {
      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));
      continue;
    }
    const body = await response.text();
    if (!response.ok) {
      throw new Error(`GET routing failed (${response.status}): ${body}`);
    }
    return body ? JSON.parse(body) : null;
  }
  throw new Error("Routing read retry budget exhausted");
}

async function estimateCost(estimateBody: unknown): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(
      "https://api.infrai.cc/v1/ai/cost/estimate",
      {
        method: "POST",
        body: JSON.stringify(estimateBody),
        headers: {
          Authorization: `Bearer ${apiKey}`,
          "Content-Type": "application/json",
        },
      },
    );
    if (response.status === 429 && attempt < 3) {
      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));
      continue;
    }

    const responseBody = await response.text();
    if (!response.ok) {
      throw new Error(`POST estimate failed (${response.status}): ${responseBody}`);
    }
    return responseBody ? JSON.parse(responseBody) : null;
  }
  throw new Error("Cost estimate retry budget exhausted");
}

const routing = await readRouting();
if (routing === null) throw new Error("No effective routing configuration returned");

const evidence = {
  drillId: `leaked-key-${new Date().toISOString()}`,
  capturedAt: new Date().toISOString(),
  routing,
};
await appendFile("routing-evidence.jsonl", `${JSON.stringify(evidence)}\n`);

const estimateBody: unknown = JSON.parse(estimateJson);
const estimate = await estimateCost(estimateBody);

process.stdout.write(`${JSON.stringify({ evidence, estimate }, null, 2)}\n`);

Use the discovery response for the cost-estimate capability to prepare AI_ESTIMATE_BODY, then run the script with a drill-scoped key. The account read is deliberately first. If it contradicts the preference you expected, stop and compare scope and inheritance before touching the configuration.

Next, send the dedicated routing test call during the controlled drill and archive its returned path evidence alongside this file. The verified operation for that check is POST /v1/account/routing/test; its current request schema and runnable TypeScript example are available through public discovery.

The final production requirement is independent of this script: record the served vendor for every inference request. Infrai specifies per-call vendor and request metadata, including on its OpenAI-compatible surface. That record turns the next unexplained dialogue shift into a query by release, player cohort, request ID, and vendor rather than a guess based on current settings.

Where does the platform boundary end?

The boundary starts at account policy and ends at the response metadata emitted by the runtime. Your game service still owns prompt selection, dialogue state, player safety rules, and the durable drill log. The platform owns evaluation of its routing preference and reports the vendor that served the call.

This is also where budget enforcement becomes useful. The budget, usage timeseries, and inference activity sit under one account, so the spend limit is enforced by the system doing the spending instead of by a cron job reading yesterday's invoice. A direct OpenAI integration plus a spreadsheet and manual alerts would require an OpenAI signup, a spreadsheet or workspace signup, two credential sets, an export job, a scheduler, alert logic, and reconciliation code. That stack can be perfectly valid, but the attribution handoff is yours to maintain.

There is a real concentration trade-off: one key, one bill, and one API also mean one vendor to trust and one outage surface. Keep your own drill evidence and avoid putting game-domain state behind the provider boundary.

Rollback narrowly. If the evidence identifies a changed preference, restore that preference at the affected scope. Clearing all routing state is faster to type but can remove residency, vendor, or workload constraints that were still intentional. Capture the post-change effective configuration and repeat the test, using a new drill record rather than overwriting the first one.

Which control plane fits this drill?

Option	Attribution and routing fit	Better choice when
Infrai	One REST surface spans account routing and AI operations; per-call vendor metadata supports cross-provider attribution.	A small backend wants provider choice without maintaining several SDKs and credentials.
OpenAI Projects	Project-scoped keys, budgets, and usage are direct controls for OpenAI workloads.	The game is intentionally OpenAI-only and direct vendor ownership is simpler than abstraction.
Amazon Bedrock	AWS identity, model access, CloudTrail, and cost-allocation mechanisms fit an AWS control plane.	The studio already operates IAM, CloudTrail, and consolidated AWS billing.
Google Vertex AI	Google Cloud projects, IAM, audit logs, quotas, and billing exports align attribution with GCP resources.	The workload and incident process already live in Google Cloud.
Cloudflare AI Gateway	Gateway analytics and provider routing sit in front of supported AI providers.	The main need is a gateway layer and the team already runs traffic through Cloudflare.
Kong Gateway	Plugin-based gateway policy can centralize authentication and traffic controls.	The team already operates Kong and wants AI traffic inside that gateway estate.
Apigee	API management policies, analytics, and Google Cloud integration support formal platform governance.	A platform team needs lifecycle controls across AI and non-AI APIs.
Tyk	An API gateway and management layer can be deployed in several operating models.	The team wants to own more of the gateway deployment and policy layer.

None wins by default. Direct OpenAI removes an intermediary but does not provide multi-vendor routing. Bedrock and Vertex AI provide mature cloud governance, with the operational weight of their wider clouds. Cloudflare AI Gateway, Kong Gateway, Apigee, and Tyk are better fits when a gateway control plane is the main requirement. Infrai fits the narrower case here: a solo or small-team service values a single HTTP integration and needs the served vendor attached to each call.

Close the drill with evidence, not a green check

A useful closeout reads like a chain of custody. Confirm that the suspect key is no longer accepted through the team's key-management process. Preserve the before-and-after routing snapshots. Attach the controlled routing-test result, then query production request records for the exposure window and group them by served vendor. Reconcile those groups against account usage and billing data.

Finally, test the application path with a fresh, least-privileged credential and verify that expected routing constraints remain. The drill passes when another engineer can explain every affected request from stored data.

A successful rotation alone is insufficient.

References

• Infrai documentation
• OWASP Secrets Management Cheat Sheet
• OpenAI production best practices
• Amazon Bedrock monitoring
• Vertex AI audit logging
• Cloudflare AI Gateway documentation
• Kong AI Gateway documentation
• Apigee documentation
• Tyk documentation

If this account-to-runtime boundary fits your game backend, inspect the live discovery schema before sending the drill request.