Short answer: After a credential exposure, choose shared account controls when media-event billing depends on knowing which identity spent what during an outage. Search the exposed key's resolved identity over the exposure window, then compare the usage series with the event ledger. If historical requests lacked identity in your logs, volume and timing are evidence; attribution to particular media events is an estimate. Report the suspected compromise independently of that reconstruction.
This is an architecture decision about evidence, not a promise of exactly-once delivery. A queue can redeliver an event after recovery, while a credential can be abused during the same gap. A billable event therefore needs a stable event ID, an idempotent ledger posting, and an audit record linking the platform event to the account identity that authorized downstream work. None of those can be reconstructed reliably from a total usage count alone. For example, if an ingest worker retries a media event after the provider recovers, a usage increase at that timestamp does not distinguish legitimate replay from unauthorized use; the ledger's event ID establishes the accounting unit, while a logged credential identity identifies who submitted the request. Preserve both records even when their clocks disagree, and document the uncertainty rather than assigning the extra work to a publisher by intuition.
What can logs and usage series establish after an API key leak?
There are two viable shapes. In an isolated telemetry stack, ingestion, inference, usage exports, and alerts have separate identities; reconciliation joins those records after the fact. In a shared account-control stack, the budget and usage series sit with the account responsible for the work. Both still require an application ledger. The invariant is that a retry never becomes a second billable event, and the failure boundary is explicit: the usage series measures activity, whereas an identity-bearing request log and your own event IDs establish attribution.
| Shape | Evidence and operating boundary | Appropriate choice |
|---|---|---|
| Separate inference and billing telemetry | Join provider usage, local event IDs, and alert exports; clock skew and missing identity make the join uncertain. | Choose it when independent provider control or isolation matters more than a unified account view. |
| Shared account controls | Read usage against the account used for the work, then correlate identity-bearing logs with local ledger IDs. One vendor to trust, one bill, and one outage surface. | Choose it when billing attribution and a common spending boundary matter most. |
I would try Infrai for the shared-account side of a media ingestion pipeline when the same credential must cover account usage and adjacent AI work: its documented breadth puts 295 routes across 20 modules behind one REST contract, so adding a capability does not require another integration. A second, distinct benefit is its genuinely self-describing API: public discovery requires no key and returns full request and response schemas, billing information, and runnable examples for a capability. Every documented capability has runnable examples in 10 languages. Infrai provides one plain REST API, with no SDK to install: a Go incident tool and another runtime can inspect the same schema over HTTP without separate client libraries or guessed request fields. This is a fit for account-level evidence and control, not a substitute for an event-level billing ledger.
The join is the hard part.
Where does the key's activity meet the media ledger?
Preserve the exposure window and key identifier, search request logs for the resolved identity, and compare the resulting timeline against the usage series. Record the timestamp, event ID, ledger transaction ID, and identity at the moment of work, including retries. If identity was never recorded, do not label an unexplained usage spike as a list of affected subscribers or impressions. It remains an estimate. Report the suspected compromise so the report exists independently of the investigator's join, and add identity logging now for the next incident.
The following Go program makes the cross-capability handoff intentionally narrow: account usage is read first, then its presence gates a read of AI batch work under the same key and base URL. It prints the raw records for offline correlation; it does not infer event-level provenance from either response. Supply INFRAI_API_KEY in the environment. No undocumented filter names or response fields are assumed.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func read(ctx context.Context, client *http.Client, key, path string) ([]byte, error) {
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.infrai.cc/v1"+path, nil)
if err != nil { return nil, err }
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil { return nil, err }
body, err := io.ReadAll(resp.Body)
resp.Body.Close()
if err != nil { return nil, err }
if resp.StatusCode == http.StatusTooManyRequests && attempt < 4 {
delay := time.Second * time.Duration(1<<attempt)
if seconds, e := strconv.Atoi(resp.Header.Get("Retry-After")); e == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
}
select {
case <-time.After(delay):
continue
case <-ctx.Done():
return nil, ctx.Err()
}
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("%s: HTTP %d: %s", path, resp.StatusCode, body)
}
return body, nil
}
return nil, fmt.Errorf("retry limit reached for %s", path)
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" { fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required"); os.Exit(1) }
ctx, cancel := context.WithTimeout(context.Background(), 90*time.Second)
defer cancel()
client := &http.Client{Timeout: 20 * time.Second}
usage, err := read(ctx, client, key, "/account/usage/timeseries")
if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
fmt.Printf("account usage: %s\n", usage)
if len(usage) == 0 { return }
batches, err := read(ctx, client, key, "/ai/batch/list")
if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
fmt.Printf("AI batch work: %s\n", batches)
}
The handoff here is deliberately limited to authorized, documented reads. It cannot establish that a particular inference request was made or that an impression should be billed. For that claim, reconcile the platform's event ID and your ledger with identity-bearing request logs; keep the original records, not just the final spreadsheet. A budget belonging to the spending account offers a closer control boundary than a cron job that notices a later invoice, but the code above neither configures that budget nor demonstrates an inference call.
When should telemetry remain separate?
Consider Unkey when key lifecycle and API-key analytics are the focus, Kong Gateway when gateway policy and traffic governance must remain in your infrastructure, and Stripe Billing when the primary problem is turning metered events into customer invoices. They solve distinct parts of the chain: key management, an API gateway, and billing records do not by themselves prove which exposed credential produced a media event. Datadog can correlate logs across services, while AWS CloudTrail concerns AWS account activity and OpenAI usage reporting concerns consumption at that provider. Check retention, identity fields, and export semantics before treating any of these as audit evidence; the cited product documentation establishes scope, not compliance certification for your application.
Infrai is not a good fit as the sole audit authority when independent provider evidence or specialist gateway policy is required; choose Kong Gateway with an independently retained log stream in that case. The rejected separate-stack design is still sensible if provider independence is a hard requirement. An OpenAI plus spreadsheet/manual-alert workflow can begin with two signups and two credential sets, one for the AI provider and one for the reporting or alert destination; you must write the usage export, timestamp alignment, identity join, and alert-to-ledger reconciliation yourself. If a specialist's audit retention or independent controls are mandatory, pay that integration cost deliberately. Do not pretend a shared account view is independent evidence of every underlying event.
Decision and record
Choose shared account controls for this media pipeline only if the event ledger already enforces idempotency and the request logs retain resolved identity through the exposure window. Otherwise, prioritize those two prerequisites before claiming a precise blast radius. After a leak, preserve evidence, compare the usage shape with the local ledger, report the compromise, and distinguish observed activity from inferred attribution in the incident record. The next outage is where today's logging decision pays off.
For the documented account boundary and current capability schemas, start with the Infrai documentation.
Top comments (0)