OpenAI Agents API sandbox: keep the Sume API key out of it

Do not put a Sume API key inside an agent sandbox or hand it to a computer-use browser. Sume's docs say a key spends your credits, has no browser-safe variant and belongs server-side, so give the agent a narrow route to your own backend, or connect it to Sume's hosted MCP with OAuth and read-only scope first.

The OpenAI API changelog lists an Agents API public beta with a managed Codex harness, durable sessions and a sandbox, plus hosted-browser computer use. Those make it easy to run an agent that touches many systems, which is exactly when credential placement matters.

What the changelog lists

Only the items relevant to credential placement are used here.

What Sume says about keys

Sume Developer API keys are workspace-scoped and are sent as Authorization: Bearer or x-api-key, never both at once. The SDK docs are explicit that a key is server-side only: never ship it to client JavaScript, a mobile bundle or a NEXT_PUBLIC_* variable, and put your own endpoint in front of Sume instead.

A sandbox that executes model-written code is, for this purpose, a client you do not fully control. Anything in its environment variables or files can end up in logs, prompts or generated output.

Three safer shapes

Pick the one that matches how much the agent should be allowed to spend.

• A proxy you own. The sandbox calls your endpoint with a task description; your server attaches the key, sets the Idempotency-Key, and returns the job envelope (job id and status URL), and the media URL once the job completes.
• Hosted MCP with OAuth. Connect to https://mcp.sume.com/mcp; the default grant is mcp:read, and Write is a separate opt-in at consent. An OAuth token is not a Sume API key and should not be stored in CLI config or pasted into prompts.
• No Sume access at all. Let the agent produce a brief and have a trusted job on your side submit the generation.

export async function POST(request: Request) {
  const { prompt } = await request.json();
  if (typeof prompt !== "string" || prompt.length > 2000) {
    return Response.json({ error: "bad_prompt" }, { status: 400 });
  }
  const res = await fetch("https://api.sume.com/v1/images", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SUME_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": request.headers.get("x-task-id") ?? crypto.randomUUID(),
    },
    body: JSON.stringify({ model: "sume/auto", prompt, mode: "async" }),
  });
  return new Response(await res.text(), { status: res.status });
}

Why a hosted browser should not hold the key either

A computer-use agent reads pages and types into fields. If a key is in its context it can be typed into a form or echoed in a transcript. Sume's credential-safety guidance is to rotate API keys that appear in logs or chat history, which is a good reason never to put one there.

The proxy above accepts only a prompt, caps its length, and forwards an x-task-id as the idempotency key so a retried agent step does not create a second paid job.

Recovering after a session restart

Durable sessions help an agent resume, but they do not tell Sume that a job already exists. Store the job id the proxy returned, and on resume read GET /v1/jobs/{id}/status rather than submitting again. A webhook with mode: "webhook" can also deliver the terminal event to your server, where the signature check happens outside the sandbox.