How to Fix 'authentication failed in production' in AutoGen (TypeScript)

If you’re seeing authentication failed in production in AutoGen TypeScript, the runtime is telling you the model provider rejected the credentials it received. In practice, this usually shows up after a local prototype works, then fails once deployed to Docker, Vercel, Azure, ECS, or a CI job.

The key detail: this is almost never an AutoGen bug. It’s usually bad environment wiring, wrong provider config, or a key that never made it into the production process.

The Most Common Cause

The #1 cause is simple: your app reads the API key from process.env, but production never gets that variable, or gets the wrong one.

With AutoGen TypeScript, this often happens when you instantiate OpenAIChatCompletionClient or another model client before env vars are loaded, or you rely on .env locally and forget to set real deployment secrets.

Broken vs fixed

// BROKEN
import { OpenAIChatCompletionClient } from "@autogenai/openai";

const modelClient = new OpenAIChatCompletionClient({
  apiKey: process.env.OPENAI_API_KEY,
  model: "gpt-4o-mini",
});

// Later you see something like:
// Error: authentication failed in production
// or
// Error: 401 Unauthorized from OpenAI API

// FIXED
import { OpenAIChatCompletionClient } from "@autogenai/openai";

const apiKey = process.env.OPENAI_API_KEY;

if (!apiKey) {
  throw new Error("Missing OPENAI_API_KEY");
}

const modelClient = new OpenAIChatCompletionClient({
  apiKey,
  model: "gpt-4o-mini",
});

If you deploy with Docker, make sure the variable is actually present in the container:

docker run -e OPENAI_API_KEY="$OPENAI_API_KEY" my-app

If you use Kubernetes, ECS, or Azure App Service, confirm the secret is mounted into the runtime environment and not just stored in your CI pipeline.

Other Possible Causes

1) Wrong provider key for the model client

A common mistake is using an OpenAI key with an Azure OpenAI endpoint, or vice versa. AutoGen will still construct the client, but the provider returns auth errors.

// Wrong: OpenAI-style config against Azure endpoint
new OpenAIChatCompletionClient({
  apiKey: process.env.OPENAI_API_KEY,
  model: "gpt-4o-mini",
  baseURL: process.env.AZURE_OPENAI_ENDPOINT,
});

Use the provider-specific client and fields:

// Right: Azure-specific config
new AzureOpenAIChatCompletionClient({
  apiKey: process.env.AZURE_OPENAI_KEY!,
  endpoint: process.env.AZURE_OPENAI_ENDPOINT!,
  deploymentName: "gpt-4o-mini",
  apiVersion: "2024-02-15-preview",
});

2) Environment variable name mismatch

Locally you might have OPEN_AI_API_KEY, while production expects OPENAI_API_KEY. That one underscore is enough to produce a 401.

const apiKey = process.env.OPEN_AI_API_KEY; // typo

Fix it by standardizing names and failing fast:

const apiKey = process.env.OPENAI_API_KEY;
if (!apiKey) throw new Error("OPENAI_API_KEY not set");

3) Secret is present in CI but not in runtime

This happens when people add secrets to GitHub Actions and assume they flow into the deployed app. They don’t unless you explicitly pass them through.

# Broken assumption: secret exists in CI only
env:
  OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

That only helps your pipeline job. Your production service still needs its own secret configuration.

4) Using an expired or revoked key

If the code was working and suddenly started failing after a rotation event, check whether the credential was revoked. AutoGen will surface it as an auth failure from the downstream provider.

Typical symptom:

• •401 Unauthorized
• •invalid_api_key
• •authentication failed
• •The API key provided is invalid

Update the secret in your deployment platform and restart the service.

How to Debug It

1. •

   Log whether the key exists, not the key itself

   console.log("OPENAI_API_KEY present:", Boolean(process.env.OPENAI_API_KEY));
   

   If this prints false in prod, stop there. Your issue is deployment wiring.

2. •

   Confirm which client you are using Check whether your code imports OpenAIChatCompletionClient, AzureOpenAIChatCompletionClient, or another provider-specific class. A mismatched client/provider combo will fail even if a key exists.

3. •

   Inspect the exact upstream error Wrap your AutoGen call and print the full exception:

   try {
     await agent.run(task);
   } catch (err) {
     console.error("AutoGen error:", err);
     throw err;
   }
   

   You want to see whether it’s a missing env var, a 401 from OpenAI/Azure, or a malformed base URL.

4. •

   Test outside AutoGen with a raw request Hit the provider directly with curl or a minimal SDK call. If raw auth fails too, AutoGen is not the problem. If raw auth works but AutoGen fails, inspect how you pass credentials into the client constructor.

Prevention

• •Validate all required env vars at startup with a hard fail.
• •Keep provider config explicit:
  • •OpenAI uses OpenAI clients and keys.
  • •Azure OpenAI uses Azure clients, endpoint, deployment name, and API version.
• •Add a deployment smoke test that initializes your AutoGen client before serving traffic.

If you want fewer production surprises, treat model credentials like database credentials: no defaults, no silent fallbacks, no assumptions about .env making it to prod.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.