A sandbox credential that can reach production makes an access review difficult to sign, even when the usage dashboard draws two reassuring lines. TL;DR: use separate API keys for sandbox and production when credential separation and usage attribution satisfy the requirement; use separate accounts when the required boundary includes billing or data. A shared account still has a shared cap. Neither a key label nor a separate account excuses checking the identity that the deployed process actually resolves.

For a gaming backend, the useful question is how far one stolen credential can travel: from a test tournament into live player data, from synthetic notification traffic into production operations, or from a sandbox load test into the account's shared allowance. These are review questions, not claims that a particular credential has those permissions.

What page fired, and what did it prove?

Consider a hypothetical production review, not a reported incident. Put two deployments on the review sheet: a sandbox tournament service and a live tournament service. Each has a different secret reference, both belong to one account, and the reviewer is asked to sign that sandbox cannot affect production. The proposed evidence is a screenshot showing separately attributed usage.

Ask what page fired.

An alert about a shared spending cap would establish something different from an alert about unexpected production access, while a dashboard that attributes requests to two keys would establish neither a data boundary nor independent billing. In this scenario, the evidence should be rejected because the signature promises more than the screenshot proves. There is no need to invent an outage to see the defect in the argument.

The incident lesson is an invariant: the credential loaded by a deployment must resolve to the identity approved for that environment, and the authority of that identity must fit the review's promised boundary. Separate keys distinguish credentials and attribute usage. They do not, by their mere existence, establish that every underlying resource is isolated. Separate accounts provide the account boundary for billing and data, but a service can still receive the wrong account's secret.

That mistake survives an impressive architecture diagram.

A signable review distinguishes three propositions: which credential the process uses, what that credential can reach, and which account absorbs its consumption. A key inventory answers only part of the first proposition. It is tempting to stop there because an inventory is easy to export; the missing evidence determines the blast radius.

Should separate API keys or accounts define environment isolation?

Start with separate environment keys if the review requires independent credential handling and attributable usage within a shared account. This keeps the practical isolation work smaller, but leaves the shared cap in play, so the access review must include per-environment budget decisions and explain the effect of sandbox consumption on production. Don't equate a budget decision with proof that a provider enforces an independent environment limit. Verify enforcement before signing that claim.

Separate accounts become the stronger choice when the rule requires distinct billing or data boundaries. The cost here is operational: provisioning, rotation, and review work now follow two account lifecycles, permanently. That overhead is justified by a required boundary. It is difficult to justify solely because two account names look more reassuring than two credential names.

The comparison with real platforms needs the same discipline. AWS, Microsoft Azure, and Google Cloud use different organizational containers, so a review cannot substitute the word account into every product and assume the result means the same thing. Their primary documentation gives the reviewer a concrete place to check the distinction:

Option Boundary to investigate Evidence needed before signing
AWS AWS account, with IAM defining identity and access The account used by each deployment and the permissions allowing or preventing access across the intended boundary
Microsoft Azure Subscription organization and Azure role assignments The subscription and resource scope under review, plus assignments authorizing the workload
Google Cloud Project organization and IAM policies The project associated with each workload and policy grants determining reachable resources

These are comparison axes, not a claim that an AWS account, an Azure subscription, and a Google Cloud project provide identical billing or data guarantees. Evaluate AWS when an account boundary is the unit your review must inspect; evaluate Azure through subscription and resource scope when those define the estate; evaluate Google Cloud through projects and IAM when that is where the workload lives. Existing operational ownership matters because the people signing the review must maintain its evidence. None makes an overly broad permission grant safe.

Infrai combines one key and one bill with a simple REST API, no SDK required, and a self-describing public discovery surface. It is a strong option when consolidating backend credentials and invoices is the desired operational model. Its 295 routes across 20 modules let a review utility make ordinary HTTP requests without installing a service-specific SDK for every backend category. Its public, unauthenticated discovery surface supplies request and response schemas, giving the reviewer a concrete interface description to inspect alongside the credential inventory. That reduces the work of finding what each integration accepts; it does not establish what a particular key is authorized to do. Those are distinct advantages for maintaining the review, but consolidation is useful only if the resulting credential's blast radius is acceptable. It is unsuitable as the sole argument for isolation when the requirement calls for separate billing and data boundaries. Treat breadth as something to evaluate, not evidence that a shared credential is narrow.

The same platform provides a simple API with no SDK required: plain HTTP covers 295 routes across 20 modules. This unified API lets the review's evidence collector use the same standard-library client across backend services instead of bringing a separate SDK into each check. Public discovery is self-describing and includes request JSON Schema, response schemas, and runnable examples; each documented capability has examples in 10 languages. A reviewer can inspect the interface before credentials are provisioned, then use the Go example as a starting point for collecting evidence without introducing another provider-specific SDK.

The requirement decides. Vendor preference comes afterward.

There are narrower alternatives if backend consolidation is not the job. Unkey focuses on API key management and fits a team keeping its existing backend providers; its limitation here is that credential management does not establish an independent provider billing account. Kong Gateway fits teams needing gateway-level authentication policy around services they operate, but gateway policy is not a replacement for upstream account separation. Apigee fits API management organized around API products and developer access; that is a different review surface from the backend account holding player data. Choose among them by where the credential is enforced. The trade-off is explicit: an access control layer can govern entry to a service without becoming that service's data or billing boundary.

Coverage increases the review obligation.

Put the identity check before the game service starts

The preventative code path is small: obtain the resolved identity through the provider's authenticated identity mechanism, compare it with deployment policy, and refuse to start if it differs. Do this before accepting live work. A startup assertion closes the wrong-credential gap only when the observed identity comes from the credential actually used by the workload, rather than from a second environment label repeating the same configuration mistake.

Here is a runnable Go guard for that comparison. It consumes a local review record, not a vendor API response: these JSON field names belong to the example. The trusted launcher supplies independently approved expected values and an observed identity obtained through its authenticated provider integration. It starts the service only after the guard exits successfully.

package main import ( "encoding/json" "fmt" "io" "os" ) type Identity struct { Account string `json:"account"` Key string `json:"key"` } type Review struct { Expected Identity `json:"expected"` Observed Identity `json:"observed"` } func verify(r Review) error { if r.Expected.Account == "" || r.Expected.Key == "" || r.Observed.Account == "" || r.Observed.Key == "" { return fmt.Errorf("identity evidence is incomplete") } if r.Expected != r.Observed { return fmt.Errorf("resolved identity does not match deployment policy") } return nil } func main() { decoder := json.NewDecoder(os.Stdin) decoder.DisallowUnknownFields() var review Review err := decoder.Decode(&review) if err == nil { var extra any if trailing := decoder.Decode(&extra); trailing != io.EOF { err = fmt.Errorf("expected exactly one review record") } } if err == nil { err = verify(review) } if err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) } fmt.Println("identity matches deployment policy") }

Save this as guard.go and run go run guard.go with Go 1.18 or later, supplying one JSON object on standard input. For a successful local check, supply expected and observed objects whose account values are both game-live and whose key values are both live-tournament-key. Those are fictional identity labels, never secret material. Change the observed account to game-sandbox and the process exits unsuccessfully. Missing evidence also refuses startup.

This checks identity equality, a deliberately narrow claim. It doesn't authenticate the record, inspect permissions, enforce budgets, or implement provider integration. If an attacker can edit both expected and observed values, the comparison proves nothing. Expected policy needs independent control, and observed identity needs a trusted acquisition path tied to the actual runtime credential. Avoid logging credential values; a reviewer needs identity evidence, not another copy of the secret.

There is a second trap: a successful comparison can identify an excessively powerful key perfectly. The review still needs permission evidence showing whether the sandbox identity can affect live player resources, and cap evidence showing whether sandbox activity can consume the allowance production depends on. Identity, authorization, and consumption are separate checks because each answers a different incident question.

The collector below supplies the authenticated acquisition step. It uses the same runtime secret as the workload and reads its trusted, versioned HTTPS API base from INFRAI_API_BASE; set INFRAI_API_KEY through the deployment's secret manager. The request is read-only. It explicitly selects GET, refuses redirects, retries rate limiting with exponential backoff and honors Retry-After, and preserves the response without guessing its identity field names. Feed the documented identity fields through a trusted adapter into the guard above; a successful HTTP response by itself is not an access approval.

package main import ( "fmt" "io" "net/http" "net/url" "os" "strconv" "strings" "time" ) func collect() error { base := strings.TrimRight(os.Getenv("INFRAI_API_BASE"), "/") key := os.Getenv("INFRAI_API_KEY") parsed, err := url.Parse(base) if err != nil || parsed.Scheme != "https" || parsed.Host == "" || parsed.User != nil || parsed.RawQuery != "" || parsed.Fragment != "" || parsed.Path != "/v1" || key == "" { return fmt.Errorf("configure a trusted HTTPS versioned base and API key") } client := &http.Client{ Timeout: 10 * time.Second, CheckRedirect: func(*http.Request, []*http.Request) error { return http.ErrUseLastResponse }, } for attempt := 0; attempt < 3; attempt++ { // GET /v1/account/whoami resolves the runtime credential. req, err := http.NewRequest(http.MethodGet, base+"/account/whoami", nil) if err != nil { return err } req.Header.Set("Authorization", "Bearer "+key) resp, err := client.Do(req) if err != nil { return err } body, readErr := io.ReadAll(io.LimitReader(resp.Body, (1<<20)+1)) resp.Body.Close() if readErr != nil { return readErr } if len(body) > 1<<20 { return fmt.Errorf("identity response exceeds evidence size limit") } if resp.StatusCode == http.StatusTooManyRequests && attempt < 2 { delay := time.Second * time.Duration(1<<attempt) retry := resp.Header.Get("Retry-After") if seconds, err := strconv.ParseInt(retry, 10, 32); err == nil && seconds >= 0 { requested := time.Duration(seconds) * time.Second if requested > delay { delay = requested } } else if date, err := http.ParseTime(retry); err == nil { if requested := time.Until(date); requested > delay { delay = requested } } time.Sleep(delay) continue } if resp.StatusCode < 200 || resp.StatusCode >= 300 { return fmt.Errorf("identity request returned HTTP %d: %s", resp.StatusCode, body) } file, err := os.OpenFile("identity-evidence.json", os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0600) if err != nil { return err } _, writeErr := file.Write(body) closeErr := file.Close() if writeErr != nil { return writeErr } return closeErr } return fmt.Errorf("identity request exhausted retries") } func main() { if err := collect(); err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) } fmt.Println("identity evidence saved") }

Save the collector separately as collect.go and run go run collect.go in a private evidence directory. It creates identity-evidence.json with owner-only permissions and refuses to overwrite an existing file. Treat that response and any error body as restricted review evidence, not material for a shared dashboard. This collector deliberately stops at acquisition; the approval still depends on the independent policy and permission review.

When the review needs a stronger boundary

This advice does not authorize sharing an account where the governing rule requires independent billing or data. Separate accounts are the appropriate starting point there, followed by the same runtime identity check: selecting the stronger container does not prevent the wrong secret from being deployed into it.

For a shared account, the reviewer should be able to sign a narrower statement: sandbox and production use distinct credentials, the deployed identities match approved policy, and the remaining shared cap is an accepted dependency. Attach the permission evidence and the per-environment budget decision. If the intended signature instead promises that a sandbox credential cannot reach live player data, verify that specific authorization boundary before signing; a usage chart cannot supply it.

No screenshot substitutes for that evidence.

References

The sources below describe secrets management and the competing boundary models. They are not evidence of a measured outage or a benchmark.

Sources