# Your Evaluation Sandbox Holds Production Authority

An evaluation environment can be disposable while its credentials are not. A practical design for separating test workloads, provider keys, and production authority.

Published: 2026-09-14

The evaluation runner is temporary. Its provider key may have been around for six months.

That is the first thing I would check before accepting that an agent test environment is safely disposable. Deleting a container ends a process. It does not necessarily end the authority that process could copy, delegate, or use somewhere else.

## What the incident establishes

In its September threat intelligence report, Anthropic describes GTG-50020 injecting instructions into an AI vendor's automated evaluation sandbox and obtaining production API keys for multiple providers. The actor used stolen credentials during further intrusion attempts. A follow-on campaign from the same infrastructure attacked roughly thirty AI companies over about four days.

The attribution needs care: Anthropic explicitly says its own systems were not compromised. These were customers' keys stolen from customers' environments. The actor's attempts to obtain a pre-release Claude model failed. Thirty targets should not become thirty confirmed breaches in a retelling. These are Anthropic's reported findings, not an independently reproduced incident analysis. [Read the GTG-50020 case study](https://www.anthropic.com/threat-intelligence-report-september-2026).

My concern is the design question this raises: what can a test workload take with it after the test ends?

## Start with effective authority

In [The Range Was Not a Boundary](/blog/the-range-was-not-a-boundary/), I focused on the difference between declared isolation and actual network access. [Your Agents Share More Than You Think](/blog/your-agents-share-more-than-you-think/) examined shared state. Credentials deserve their own review because they can remain useful outside both boundaries.

For an AISecOps program, I would inventory evaluation access with the same care as deployment access. That does not mean labeling every key a Tier 0 asset. A tightly limited inference credential and an organization administrator token have different consequences.

Classify the authority, then choose the protection.

| Record | What the reviewer needs to establish |
| --- | --- |
| Owner and purpose | Who needs this access, and which evaluation requires it? |
| Provider and account | Which organization, project, or subscription pays for and governs it? |
| Permitted operations | Inference only, data access, file operations, deployment, or administration? |
| Exposure path | Can the model, shell, child process, notebook, or artifact writer read it? |
| Lifetime | When does access expire, and what terminates it early? |
| Direct-use restrictions | Can a copied credential work outside the approved runner or gateway? |
| Evidence and revocation | Who can identify its use and prove that revocation worked? |

“Stored in the secret manager” answers only part of that review. The more important question is what happens after retrieval.

## Keep the secret out of the task environment

Consider a proposed architecture with three separate responsibilities.

The evaluation runner executes the test. A credential broker authenticates that runner and permits a narrow set of provider requests. The provider receives the request with the credential attached by the broker.

The runner should receive a short-lived identity for that run, not the broker's underlying provider key. The broker should live outside the runner's readable files, environment variables, and process boundary.

This is useful even when a provider requires a persistent API key. The key can remain persistent inside the broker while the runner's permission to request specific operations expires. Those are separate lifetimes.

A broker is also a service that needs a threat model. I would require it to enforce destination, account, model, operation, request-size, and budget constraints where the provider supports them. It must not accept an arbitrary destination and forward its credentials there. Responses and errors must not disclose authentication headers. Administrative provider operations should not ride through a route intended for inference.

Where supported, provider-side network restrictions add another constraint on direct use of a stolen key. Where they are unavailable, document that limitation and compensate with narrower accounts, smaller budgets, monitoring, and tested revocation.

None of this makes hostile evaluation content trustworthy. It reduces what successful instruction manipulation can reach.

## Separate the accounts as well as the containers

I would give evaluations their own provider projects or accounts where practical. Production serving should not share a credential just because both workloads call the same model.

That separation makes several operational decisions easier:

- Stop evaluation access without interrupting customer traffic.
- Attribute spend and rate-limit consumption to testing.
- Keep evaluation uploads and stored outputs apart from production data.
- Review test access without inheriting production exceptions.

Some integration tests need a live endpoint. That is a reason to define a narrow exception, not to give every benchmark runner the application's complete environment file.

The exception should identify the endpoint, allowed data, permitted operations, owner, and end date. Tests requiring real customer data need a separate data-handling decision. “More realistic” is not sufficient justification on its own.

## Trace the use you can actually observe

Agent traces can show requests made through your application. They cannot, by themselves, show a copied key being used directly from another machine.

I would join three kinds of evidence: runner identity and run records, broker authorization events, and provider-side usage or audit records where available. Use provider credential identifiers or internal opaque references, never raw secrets in logs.

Useful review signals include activity after a run ends, an unexpected account or model, usage without a corresponding broker record, and a spend increase inconsistent with the evaluation schedule. Each needs baselines and a statement of coverage. Delayed billing exports are not real-time detection, and some providers do not expose enough detail to attribute individual calls.

This is also why I would not promise to detect a campaign spanning unrelated companies from one organization's tracing platform. Visibility must be established before writing the detection requirement.

## Prove that stopping the run stops its access

Here is the exercise I would put into the platform's acceptance tests. Use a dedicated test identity, harmless requests, synthetic data, and a small budget.

1. Start an approved evaluation and confirm that an allowed request succeeds.
2. Attempt a different provider destination and an administrative operation. Both should be denied by the intended enforcement point.
3. Confirm that the runner cannot read the broker's provider secret through its exposed tools or child processes.
4. End the run. Retry using its expired or revoked runner identity from the same environment and a controlled second client.
5. Revoke a dedicated test provider credential and check that direct use fails too. Never copy a production key into this exercise.
6. Verify the handling of already accepted requests, active streams, queued jobs, and any delegated credentials. Revocation may not undo work already in progress.
7. Retrieve the evidence showing what was denied, when, and by which control.

These are proposed tests, not tests I have run against the affected vendor. A result should include propagation delays and unsupported cases, not merely a screenshot of a disabled key.

## Give the exception somewhere to live

The platform owner should maintain this register with the identity and incident-response teams. Evaluation owners supply the purpose and required access. Security reviews the consequences and tests the boundary.

That fits alongside the entitlement decisions in [Vendor Approval Is Not Your Authorization Model](/blog/vendor-approval-is-not-your-authorization-model/). Approval to use a model does not settle how a test runner receives access to it.

Before the next evaluation launch, pick one runner and follow its credentials from issuance through disposal. If nobody can show when those credentials stop working, deleting the runner is not the end of the test.