The agent's code calls the OpenAI and Anthropic libraries as they ship, and never holds the key

The headline numbers, each a check computed from the files beside this page (13 of 13 hold):

Run on 2026-10-29, with openai 3.41.0 and anthropic 2.3.0 on Python 3.14.8, on one development machine. Every run's run record (INTERNAL · glossary →), plimsoll's statement of what was sent, what came back and where it ran, is signed into bundle.jsonl.

The 30-second version

The two profiles this run used, as the daemon read them from its grants file (grants.json; the base URLs are the stub's two loopback ports):

{
  "openai": {
    "base_url": "http://127.0.0.1:45519",
    "allow": [
      "POST /v1/chat/completions",
      "POST /v1/files"
    ],
    "sdk_env": {
      "OPENAI_API_KEY": "dummy-openai-key-in-the-sandbox",
      "OPENAI_BASE_URL": "{origin}/v1"
    },
    "route_max_request_bytes": {
      "POST /v1/files": 16777216
    },
    "route_content_types": {
      "POST /v1/files": [
        "multipart/form-data"
      ]
    },
    "max_request_bytes": 67108864,
    "allowed_callers": [
      "sdk-grants-example"
    ],
    "token": {
      "type": "static",
      "env": "STUB_OPENAI_KEY"
    }
  }
}

{
  "anthropic": {
    "base_url": "http://127.0.0.1:43323",
    "allow": [
      "POST /v1/messages"
    ],
    "pass_headers": [
      "anthropic-version"
    ],
    "sdk_env": {
      "ANTHROPIC_API_KEY": "dummy-anthropic-key-in-the-sandbox",
      "ANTHROPIC_BASE_URL": "{origin}"
    },
    "allowed_callers": [
      "sdk-grants-example"
    ],
    "token": {
      "type": "static",
      "env": "STUB_ANTHROPIC_KEY"
    }
  }
}

What the guest's environment held

The guest (INTERNAL · glossary →), the code running in the sandbox, printed its whole environment, and the environment of every process it could see. These are the variables the profile's sdk_env set, as each run's guest saw them:

The key is a placeholder: both libraries refuse to start without one, and the broker replaces whatever the library sends. The keys the daemon held appear nowhere in what any run was sent or answered: not in the guest's environment, not in its output. The program searched the stored requests and answers in the signed bundle for each key, byte for byte. Each guest could read the environment of its own process and of no other: in the OpenAI run, pid 1, node --eval (PermissionError errno 13) and pid 13, node /runner.mjs (PermissionError errno 13) refused it (errno 13 is permission denied). Those two are plimsoll's own: the forwarder and the project runner. The Anthropic run's guest saw the same 2 refusals.

What the library sent, and what the API received

For one call of each library: every header as the library sent it to the local address (read back through the library's own with_raw_response, which adds its x-stainless-raw-response header), beside the same header as the stub received it from the broker.

OpenAI: client.chat.completions.create(...)

Sent to http://127.0.0.1:8471/v1/chat/completions; the stub received POST /v1/chat/completions and answered 200: “Hello from the stub API.”

Anthropic: client.messages.create(...)

Sent to http://127.0.0.1:8471/v1/messages; the stub received POST /v1/messages and answered 200: “Hello from the stub API.”

In the two tables: the library's key (Authorization: Bearer dummy-…) never left the broker: the API got the daemon's key in its place. The library's User-Agent gave way to the broker's own, and the x-stainless-* headers both libraries send (their telemetry: language, version, operating system, retry count) were dropped. So were the two headers the guest added on purpose: OpenAI-Organization, which would let the guest choose which organization a call is billed to, and anthropic-beta, the header that switches on a beta feature, server-side tools among them. The transport headers (Accept, Content-Type, Host and the like) are the broker's, set on every request it makes. Of the headers the library chose, only anthropic-version, which the Claude API requires and the profile lists in pass_headers, was copied through. The broker sends every key as Authorization: Bearer, which is how the Claude API documents sending an API key (authentication (EXTERNAL · official docs ↗), read 2026-10-29; x-api-key is its older header).

The stream, piece by piece

A streamed answer comes back as server-sent events (EXTERNAL · official docs ↗): one HTTP response whose body is a series of small events, written as the model produces them. The stub waited 400 ms between pieces. Had anything on the way held the answer until it ended (the broker, the forwarder or the library), every piece would have reached the library after the stub wrote the last one. Instead, each piece reached the library before the stub had written the next. The times are from one clock: the stub and the sandbox run on the same Linux kernel, and a container reads the host's wall clock.

OpenAI: stream=True, 8 chunks

Each dark mark is the stub writing a piece; the teal mark below it is the library handing that piece to the guest's loop. The longest wait from a write to its arrival: 2 ms. First to last arrival: 2804 ms. The hollow mark is the stub's last write, data: [DONE], which ends an OpenAI stream: the library reads it and hands no piece over. Each piece's text is the one the stub wrote (8 of 8).

Anthropic: stream=True, 13 events

The Claude stream sends named events: a start, the text deltas, a stop. The longest wait from a write to its arrival: 4 ms. First to last arrival: 4807 ms. Each event's type and text are the ones the stub wrote (13 of 13).

The upload

The guest uploaded 8 MiB with client.files.create(file=("sample.bin", data, "application/octet-stream"), purpose="user_data"). The library sends that as multipart/form-data (EXTERNAL · official docs ↗), one request body in named parts. A route takes a body over 1 MiB only when its profile raises the route's limit and names the type: here POST /v1/files is raised to 16 MiB and takes multipart/form-data, and the run may send 64 MiB in all.

The guest computed SHA-256 fa16e68dc6e4ff55d4eaf64f51a79ea3d3444b4b128c6856137e74b008605a06 over the bytes it sent; the stub computed fa16e68dc6e4ff55d4eaf64f51a79ea3d3444b4b128c6856137e74b008605a06 over the file part it received, the same. The whole request body the stub received was 8388891 bytes, and the library got back the stub's file object, file-stub-1.

The refusal

The guest called client.embeddings.create(model="stub-embedding", input="hello"), which is POST /v1/embeddings. The OpenAI profile allows POST /v1/chat/completions and POST /v1/files and nothing else. The library raised PermissionDeniedError, status 403, with the broker's own answer:

forbidden by sandbox capability allowlist

Three things show that the broker refused it and the API never saw it. The stub serves /v1/embeddings and would have answered 200, yet it received 0 requests there. The answer carries X-Should-Retry: false, which every answer the broker makes itself carries, and the library honors it: the attempt that raised was its first (x-stainless-retry-count: 0), so the refusal spent no further calls. And the daemon's audit line for the run counts 1 call denied by policy.

The call trace, as the daemon reports it

The broker keeps a metadata-only list of each run's calls: the route pattern each matched, its status, its sizes and its time, never a path, a body or a key. The daemon does not send that list back with the answer; it reports it as counts on the run's audit line (the line the daemon logs for every run) and per route in /metrics (the counters it serves to monitoring), both read after the runs:

The latency is the broker's round trip to the stub and back for the calls of that route, summed; for the streamed calls it includes the stub's 400 ms waits.

The run records, and the second seccomp profile

Each record states where its run ran: the isolation tier (INTERNAL · glossary →), how strong the wall around it was; the image, the packaged file system the sandbox started from, by its content identity; and the policy. The policy field names the seccomp (INTERNAL · glossary →) profile docker applied to the run, the kernel's list of the operations a program may ask it for, by the SHA-256 of its bytes. The shipped default allows Unix sockets only, so under it no forwarder could listen. A run whose grant sets sdk_env gets a second profile, which the daemon derives from the default at startup (SANDBOX_DOCKER_SECCOMP_SDK=derived) and pins by its digest, so the two records below name different profiles:

Both profiles are published beside this page: seccomp-default.json (8.2 KiB, the repository's docker/seccomp.json, SHA-256 a39bc7bf6cf7…) and seccomp-sdk.json (13.0 KiB, the bytes the daemon pinned, c5b32b1a17c3…). The daemon's own description of the pair, as it stated it: seccomp:sha256:a39bc7bf6cf712f4d65d108f615aeae5785d8def8bc0e658fbd4e36a6305b089 sdk_env:seccomp:sha256:c5b32b1a17c39da0438800a99bd0607700877ac8d01b72b839394023f0d64376. Compared one syscall rule at a time, the variant keeps 243 of the default's rules as they are, takes out 2 and adds 10:

In words: socket may now make an IPv4 (AF_INET, 2) TCP stream socket, and nothing else new; setsockopt and getsockopt, which the default allows with any arguments, are allowed only for the few options the forwarder and the libraries set. What each run's guest tried, and got:

192.0.2.1 is set aside for documentation (RFC 5737 (EXTERNAL · official docs ↗)): the address only shows whether the sandbox has a route out, and under --network none it has none. The added sockets reach only the container's loopback, but they are kernel code the default withholds, which is why the variant is a profile of its own and applies only to runs whose grant sets sdk_env; docs/seccomp.md (EXTERNAL · official docs ↗) says what it adds in full.

What this proves, and what it doesn't

Run it yourself

From a clone of the repository (EXTERNAL · source repo ↗), with docker:

make docker-images                    # plimsoll's sandbox images, plimsoll/sandbox-python among them
go run ./examples/sdk-grants          # builds the example's image and plimsolld, runs everything, rewrites this page
go run ./examples/sdk-grants -verify  # rechecks the files beside this page; starts nothing
go run ./cmd/plimsoll-attest verify -pub docs/examples/sdk-grants/harness.pub docs/examples/sdk-grants/bundle.jsonl

The example's image is plimsoll's Python image with the two libraries installed from wheels (Python's package files) pinned by version and SHA-256 (requirements.txt (EXTERNAL · source repo ↗), 17 packages): openai 3.41.0 (EXTERNAL · package index ↗, wheel 7060a74b2396…) and anthropic 2.3.0 (EXTERNAL · package index ↗, wheel aa6a3984f927…). Building it fetches those wheels; the runs have no network. Image plimsoll-wip/sdk-grants:dev, bf5af9606ed3, built on plimsoll/sandbox-python:latest, 48666c14b387. The program spends nothing: no model, no paid sandbox. Everything on this page comes from evidence.json, which -verify rebuilds from these files:

• bundle.jsonl, 45237 bytes
• harness.pub, 113 bytes
• observations.dsse.json, 6687 bytes
• stub.jsonl, 6144 bytes
• grants.json, 1156 bytes
• seccomp-default.json, 8388 bytes
• seccomp-sdk.json, 13327 bytes

observations.dsse.json is the harness's signed statement (a DSSE (INTERNAL · glossary →) envelope, the signing format the run records use) of what it saw outside the runs (the daemon's description of itself, its audit lines and /metrics, the image, the keys it handed the daemon, and the SHA-256 of the stub's log, the grants file and both profiles), naming the three run records. The keys are random values made for this run; they open nothing but the stub, which no longer runs. Harness key ID 9264f8cf24ee225014c4359279b8b3513ffca1e771b2f4719b148404ce21d7c7.