AI gateway provenance and request attribution
Gateway provenance is the record connecting a provider request to the downstream workload authorized to initiate it. The challenge is preserving that connection across authentication, routing, retries, and billing without exporting raw credentials or prompt content.
Map each identity boundary
Draw the path from client to gateway to provider. At each hop, identify who authenticates the caller, which credential is presented, which identity is recorded, and which identifiers survive forwarding. A provider may see only the gateway credential while the gateway knows the downstream tenant.
| Boundary | Record to retain | Trust question |
|---|---|---|
| Client to gateway | Authenticated principal, permitted workload, logical request ID | Did the gateway verify this identity? |
| Gateway routing | Route decision, attempt ID, deployment and model | Can a fallback be distinguished from a second user request? |
| Gateway to provider | Upstream request reference and credential reference | Which principal was represented upstream? |
| Usage to billing | Attempt-level usage and reconciliation status | Was usage recorded once at each intended accounting layer? |
Do not promote labels into authentication
A client-supplied user ID or request header may help correlate events, but it does not become trustworthy simply because it appears in a log. Record where it originated and whether a trusted service verified it. Treat forwarded network information according to the configured proxy trust boundary.
A shared IP is not a stable downstream identity. Equally, a unique trace identifier is not proof that the initiating workload was permitted. Correlation and authorization answer different questions.
Handle one request becoming several attempts
Synthetic example: logical request R creates attempt A at provider one, which times out, then attempt B at provider two, which succeeds. Both attempts may have operational or billing significance. Keep R as the correlation parent and A/B as distinct attempts. Deduplicating everything by R could hide the first attempt; counting repeated deliveries of A as new attempts could inflate usage.
Record unknown upstream outcomes explicitly. A timeout observed by the gateway does not prove the provider performed no work. Reconcile late usage records without replacing earlier evidence silently.
Build a reconciliation check
- Select a known request window and count logical requests, attempts, and delivered events separately.
- Join gateway attempts to provider references where the provider exposes them.
- List unmatched records and distinguish delayed delivery from permanently missing correlation.
- Compare recorded usage using the same scope, currency, and pricing basis.
- Measure coverage before relying on the joins in an abuse investigation.
What to do when the chain is incomplete
Document the last verified identity boundary. Request the missing records from the authorized operator where possible. Do not infer a downstream person's identity from provider-side timing alone. Improve collection for future events without claiming to have reconstructed historical data that was never retained.
Use the logging field guide to define the records, gateway credential-misuse guide to investigate a case, and authorization guide to make the final decision.