Windmill AI agent API key: scoping vendor calls in developer workflow scripts

How Windmill AI agent scripts call vendor APIs

Windmill scripts are functions with typed inputs and outputs. A billing agent flow might look like this — a for-each step that runs a charge script for each customer ID in a list:

// charge_customer.ts — Windmill TypeScript script
import Stripe from "npm:stripe";

type Params = {
  customer_id: string;
  amount_cents: number;
  stripe_resource: {  // Windmill resource variable — full-access key
    secret_key: string;
  };
};

export async function main({ customer_id, amount_cents, stripe_resource }: Params) {
  const stripe = new Stripe(stripe_resource.secret_key);  // full-access key
  const intent = await stripe.paymentIntents.create({
    amount: amount_cents,
    currency: "usd",
    customer: customer_id,
  });
  return { payment_intent_id: intent.id, status: intent.status };
}

In the Windmill flow editor, the stripe_resource input is connected to a Windmill resource variable (the equivalent of a secrets store entry). When the flow runs a for-each step over this script, each parallel execution reads the same Windmill resource — the full-access Stripe key — and makes an independent call to Stripe. There is no mechanism in the Windmill flow to cap total vendor spend across the for-each iterations.

Three gaps Windmill's native tooling doesn't fill for vendor spend control

The for-each risk: parallel worker spawning and simultaneous vendor calls

Windmill's for-each flow step is the primary fan-out mechanism for list-based agent workloads. Each item in the input array spawns an independent worker job. Worker concurrency is bounded by the workspace's worker pool capacity (configurable in self-hosted deployments or by plan in cloud), but not by vendor spend. On Windmill cloud plans with adequate worker capacity, 200 for-each items can all run simultaneously.

Windmill's concurrency limit setting controls how many iterations run at once, but it's a throughput control, not a spend cap. Setting concurrency to 5 means the 200 charges happen over 40 batches instead of 1 batch — the total spend is identical, it just takes longer. A vault key with a dollar cap fires at the total spend limit regardless of concurrency setting.

Scoping vault keys per Windmill flow run

Add an issue_vault_key script as step 1 in the flow. Bind its output to the downstream charge scripts using Windmill's input binding:

// issue_vault_key.ts — Step 1 in the flow
type Params = {
  keybrake_api_key: string;  // Windmill resource: keybrake credentials
  budget_usd: number;
};

export async function main({ keybrake_api_key, budget_usd }: Params) {
  const res = await fetch("https://proxy.keybrake.com/vault/keys", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${keybrake_api_key}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      vendor: "stripe",
      daily_usd_cap: budget_usd,
      allowed_endpoints: ["POST /v1/payment_intents"],
      expires_in: "2h",
      agent_run_label: `windmill/${Deno.env.get("WM_FLOW_JOB_ID") ?? "local"}`,
    }),
  });
  const { vault_key } = await res.json();
  return { vault_key };  // output bound to downstream steps
}

// charge_customer.ts — Step 2 (for-each over customer_ids)
import Stripe from "npm:stripe";

type Params = {
  customer_id: string;
  amount_cents: number;
  vault_key: string;  // bound to step 1's output.vault_key in flow editor
};

export async function main({ customer_id, amount_cents, vault_key }: Params) {
  const stripe = new Stripe(vault_key, {
    apiVersion: "2024-06-20",
  });
  // Override the base URL to route through the proxy
  (stripe as any)._api.basePath = "https://proxy.keybrake.com/stripe";

  const intent = await stripe.paymentIntents.create({
    amount: amount_cents,
    currency: "usd",
    customer: customer_id,
    idempotency_key: `${Deno.env.get("WM_FLOW_JOB_ID")}-${customer_id}`,
  });
  return { payment_intent_id: intent.id };
}

In the Windmill flow editor, connect the vault_key input of the for-each step to results.step1.vault_key. All for-each iterations receive the same vault key — scoped to this flow run's budget. The Windmill resource variable now contains only the Keybrake API key (used once in step 1), not the real Stripe secret. Revoking a runaway flow run is a single DELETE /vault/keys/{key_id} call against the Keybrake API — the vault key expires immediately on the next vendor call from any worker in the flow.

How Keybrake fits

Keybrake is the proxy layer between your Windmill scripts and Stripe, Twilio, or Resend. The vault key replaces the full-access API key that previously lived in a Windmill resource variable. Each flow execution issues its own vault key with its own dollar cap and TTL. When a flow is re-triggered (scheduled re-run, webhook re-delivery), the new execution issues a fresh vault key — so previous runs' caps don't carry over. The real vendor secret stays in Keybrake regardless of how many Windmill workspaces, flows, or script versions use it.

Get early access

Related questions

Further reading

• n8n AI agent API key — n8n's split-in-batches node creates the same fan-out risk as Windmill's for-each steps; the vault-key injection approach is similar.
• Temporal AI agent API key — for AI agents with more complex state machines and long-running workflows requiring durable execution.
• AI agent credential management — comparison of secrets management approaches (environment variables, secrets managers, vault keys) for workflow platforms.
• AI agent cost management — the four cost categories in AI agent deployments and why vendor API spend is the most unpredictable.