A coding agent needs to access cloud resources, but you do not want the model or generated code to see reusable credentials. How would you implement credential-blind execution, and what would you log or revoke if you detected attempted exfiltration?

How to think about it

I would run generated code in an ephemeral sandbox with no cloud credentials, metadata access, or unrestricted network egress, and put every cloud operation behind a server-side policy broker. The broker uses a tightly scoped workload identity, while I log the attempted action and provenance, terminate the run, and revoke its capability or session if the agent tries to exfiltrate anything.

Why this is the mechanism being tested

The important boundary is not between the model and the code. Both are untrusted.

A model can generate:

print(open("/proc/1/environ").read())

It can also inspect environment variables, search mounted files, query a cloud metadata service, read shell history, or post data to an external server. Telling it not to do those things is not a security control. The environment variable is not a vault; it is a labeled drawer.

Credential-blind execution means that neither the model nor its generated process ever receives reusable credential material. The code can request an approved operation, such as reading one object from storage, but it cannot obtain the access token, secret key, private signing key, or refresh token used to perform that operation.

The usual architecture has four parts:

1. An ephemeral sandbox runs the generated code. It has a short lifetime, an immutable image, a temporary filesystem, no host socket, no secret-bearing environment variables, and no route to the cloud metadata service.
2. Network policy allows the sandbox to reach only an internal broker. Direct internet egress is denied at the container, VM, or network layer, not merely by convention.
3. The broker authenticates and authorizes each request. It checks the requested action, resource, tenant, arguments, rate, response size, and the agent’s capability.
4. The broker performs the cloud call using its own workload identity. That identity could be an AWS IAM role, an Azure managed identity, or a Google Cloud service account. If the broker needs a short-lived provider token, that token stays inside the broker’s trust boundary.

The broker can execute the operation itself, or sign and forward a request without returning the authorization header to the sandbox. The first option is easier to reason about. The second can support more cloud APIs, but it needs careful request canonicalization and strict destination controls.

A “tool call” is not automatically safe. If the agent can make arbitrary HTTP requests, or if a sidecar injects a cloud token into the process, the code can still steal the token. The control is the combination of no credential visibility, restricted egress, and authorization outside the generated process.

A concrete example

Suppose an agent is asked:

Find failed invoices from yesterday in production storage and summarize them.

The policy broker might allow:

• s3:GetObject
• only under s3://reports-prod/failed-invoices/2026-08-27/
• maximum object size of 10 megabytes
• maximum 100 requests per minute
• no PutObject, DeleteObject, bucket listing, or access to other tenants

The sandbox receives no AWS credentials. It calls an internal service using an application-level request like this:

import json
import urllib.request

request_body = json.dumps({
    "action": "s3:GetObject",
    "bucket": "reports-prod",
    "key": "failed-invoices/2026-08-27/invoice-0042.json"
}).encode("utf-8")

request = urllib.request.Request(
    "http://127.0.0.1:8080/cloud",
    data=request_body,
    headers={"Content-Type": "application/json"},
    method="POST",
)

with urllib.request.urlopen(request, timeout=5) as response:
    result = json.load(response)

print(result["text"])

The URL here is an internal endpoint defined by the platform, not a public cloud API. The broker validates the bucket and key against the policy, performs the storage request using its own identity, and returns only the permitted object content.

If the generated code changes the request to PutObject, the broker rejects it. If it tries to reach 169.254.169.254, where common cloud metadata services listen, the network layer blocks it before it can obtain anything. If it tries to send the invoice contents to an outside address, egress policy blocks that too.

The agent can still misuse authorized data. Credential blindness does not mean data blindness. If the broker returns a customer’s secret file, the model can repeat that secret in its answer. Data minimization matters: return the smallest useful fields, cap result sizes, redact known secret formats, and apply output checks before data leaves the system.

What I would log

I would make the audit trail useful for reconstructing the 3 a.m. incident without putting another copy of the secret in the logs.

For every broker request, record:

• run ID, tenant, agent identity, sandbox ID, and parent task ID
• immutable sandbox image digest and generated-code hash
• requested action and normalized resource identifier
• policy version, allow or deny decision, and denial reason
• broker identity, cloud request ID, latency, result size, and rate-limit state
• whether the result was truncated or redacted

For the sandbox, record security events such as:

• process tree and executed command names
• attempted reads of sensitive paths
• access to environment variable names, without values
• blocked DNS queries and destination addresses
• blocked connection attempts, ports, and byte counts
• attempts to access metadata services, host sockets, or credential files
• hashes of quarantined outputs and artifacts

Enable the cloud provider’s audit trail for the broker identity, including data-plane events where the provider supports them. Cloud management logs alone may show that a role was used, but not every object read. Network flow logs and DNS logs help correlate a suspicious cloud read with an attempted external connection.

Never log authorization headers, session tokens, private keys, cookies, complete environment dumps, or raw pre-signed URLs. Store sensitive evidence in a restricted incident system only when necessary, with redaction and access auditing.

What I would revoke

An exfiltration attempt is a containment event, even if the network request was blocked.

First, stop the sandbox and cancel queued tool calls. Invalidate the broker capability for that run, close its session, and prevent the model from continuing with the same identity. Quarantine generated files and outputs rather than handing them back to the user or feeding them into another automated step.

Next, revoke the cloud-side access that could have been used. The exact action depends on the provider:

• expire or invalidate the broker’s short-lived lease
• apply an emergency deny or disable the broker role if a session may still be active
• revoke pre-signed URLs or capability URLs issued to the run
• rotate any long-lived key that may have crossed the trust boundary
• revoke refresh tokens through the identity provider when those are involved

There is no universal “delete this cloud session token” button. Some temporary provider credentials cannot be individually revoked immediately, so the safe response is to deny the role or identity, reduce its permissions, and wait for the token’s short lifetime to end. That is why the broker should use a separate, narrowly permissioned identity rather than a broad production role.

Then search the audit trail backward. Determine whether the agent read more data than the task required, whether any external connection succeeded, and whether the same sandbox image or policy was used by other runs.

The senior-level nuance

The cleanest design is not always the most flexible. A tool broker means adding an operation to the broker when a team needs a new cloud feature. That creates development and latency costs, and overly rigid allowlists can make legitimate work painful.

If arbitrary SDK use is essential, a controlled signing proxy can be a compromise: the code submits a normalized request, the proxy signs it, and the proxy forwards it without exposing credentials or allowing a caller-selected destination. But this creates more attack surface. Request paths, headers, resource names, redirects, and response sizes must all be validated. Otherwise the “signing proxy” becomes a very efficient credential oracle.

A common failure mode is to remove the token from the environment but leave unrestricted internet access. The first symptom is often a blocked or successful DNS lookup to an unfamiliar domain followed by an outbound POST containing a large response. Another is a generated script attempting to read /proc, shell history, or the cloud metadata endpoint. Treat those as telemetry from the defense, not as proof that the sandbox is safe.

What they’ll ask next

“Why not give the code short-lived credentials?”
Short lifetimes reduce blast radius, but they do not make credentials invisible. The code can still copy a 15-minute token to an attacker. Use short-lived credentials inside the broker, not inside the untrusted process.

“Can the agent use a normal cloud SDK?”
Only through an approved broker or signing proxy. A normal SDK expects credentials somewhere. If those credentials are injected into the agent process, the design is no longer credential-blind.

“What counts as attempted exfiltration?”
Examples include metadata-service access, reading credential-bearing files, enumerating environment values, sending tool output to an unapproved destination, or trying to place secrets in logs, artifacts, URLs, or model-visible error messages.

One line to say in the room

“Generated code gets capabilities, not credentials: it runs in a disposable, egress-restricted sandbox, while a policy broker performs the cloud operation and gives me the audit and revocation point.”