Make.com · AI agents · API key security

Make.com AI agent API key: scoping vendor calls with spend caps

Make.com's AI modules — OpenAI Chat, Claude, and custom AI steps — let you build scenarios where the model decides what actions to take. When that model decides to call Stripe or Twilio, the HTTP module that makes the call holds your real API key with no per-scenario dollar cap and no way to revoke access for a single scenario run. This page covers what Make's built-in connection management doesn't provide for AI-driven scenarios, and the proxy pattern that adds spending boundaries without rebuilding your automations.

TL;DR

Make's native connections encrypt your API keys and make them easy to reuse across scenarios — that's good. But a connection is binary: the scenario either has the full key or it doesn't. There's no per-scenario daily dollar cap, no way to revoke a single scenario run's access without breaking all other scenarios using the same connection, and no per-call audit log that ties each Stripe charge to the specific scenario run and AI reasoning that caused it. The vault-key proxy is a one-module change: swap the HTTP module's base URL from api.stripe.com to proxy.keybrake.com/stripe and replace the real key in the Authorization header with a scoped vault key. The rest of your scenario stays the same.

How Make.com AI scenarios call vendor APIs today

Make.com scenarios with AI decision-making typically follow one of two patterns:

Pattern A — AI module drives HTTP module actions. A Claude or OpenAI Chat module processes input and its output (via a Router or a text-extraction step) determines what the downstream HTTP module does. The HTTP module holds the real Stripe or Twilio API key in its connection or Authorization header.

Pattern B — AI function calling via the HTTP module. The AI module is configured with a tool/function definition; Make maps the AI's function call output directly into an HTTP module call. This is the "agentic" pattern: the model decides which API endpoint to call and with what parameters.

In both cases, the vendor API call is made with a full, long-lived API key stored in Make's connection manager. The AI module's output shapes the call, but the key itself has no spending limits attached to it at the Make layer.

The three gaps Make's native connections don't fill for AI-driven scenarios

Gap	What happens in practice	Make's current answer
No per-scenario spend cap	An AI scenario that processes customer requests and decides to charge them has no internal ceiling. If the AI produces unexpectedly large amounts, or if the scenario is triggered repeatedly by a buggy upstream webhook, real charges accumulate with no pre-charge stopping mechanism at the Make layer.	Make's operations limit (per team plan) caps how many modules run per month — but that's a platform cost guard, not a vendor API spend guard. A scenario can complete within its operation quota while generating $10,000 in Stripe charges.
No per-run revoke	If you need to stop a specific scenario execution from making further Stripe calls — because the AI produced bad output and the run is mid-flight — your only option is to disable the entire connection or rotate the real Stripe key, which breaks all other scenarios using that connection.	Scenario deactivation and run history exist, but they don't cancel in-flight HTTP module calls or revoke credential access for a specific execution.
No per-call audit log with AI context	Make's execution history shows module inputs/outputs, but doesn't parse the dollar amount from each Stripe response, doesn't aggregate total spend per scenario run, and doesn't cross-reference the AI module's reasoning with the vendor calls it triggered.	Execution log (module-level). No cost parsing from Stripe responses, no queryable spend-by-run report.

Swapping the HTTP module to use a vault key

The change is minimal. In your HTTP module that calls Stripe, two fields change:

Before (direct Stripe):

URL:      https://api.stripe.com/v1/payment_intents
Method:   POST
Headers:  Authorization: Bearer sk_live_xxxxxxxxxxxx   ← real key, no cap
Body:     { "amount": {{AI_output.amount}}, "currency": "usd", "customer": {{AI_output.customer_id}} }

After (via vault key proxy):

URL:      https://proxy.keybrake.com/stripe/v1/payment_intents
Method:   POST
Headers:  Authorization: Bearer vault_key_xxxxxxxxxxxxx  ← scoped key with cap
Body:     { "amount": {{AI_output.amount}}, "currency": "usd", "customer": {{AI_output.customer_id}} }

The vault key is created once per scenario (or once per execution for tighter isolation) via a preceding HTTP module call to Keybrake:

POST https://proxy.keybrake.com/vault/keys
Authorization: Bearer {{KEYBRAKE_API_KEY}}
Content-Type: application/json

{
  "vendor": "stripe",
  "daily_usd_cap": 500,
  "allowed_endpoints": ["POST /v1/payment_intents", "GET /v1/customers/*"],
  "expires_in": "2h",
  "agent_run_label": "make-billing-scenario/{{execution_id}}"
}

The response contains the vault key. A subsequent Set Variable module stores it, and all downstream HTTP modules that need to call Stripe use this vault key instead of the real key. The real Stripe key stays in Keybrake — it never passes through Make's modules.

Per-scenario vs per-execution vault keys

You have two isolation strategies:

One vault key per scenario (shared across runs). Simpler to set up — issue the key once, store it as a Make Data Store variable or a custom variable, and all runs of the scenario use it. The daily cap applies across all runs of that scenario. This is appropriate for scenarios with predictable, bounded call volume.

One vault key per execution. Add an HTTP module at the top of your scenario that issues a fresh vault key for this execution. Pass it through the scenario via Set Variable. Each execution has its own cap and its own audit trail segment. This is appropriate for scenarios where executions are independent — a customer-triggered payment, for example — and you want per-execution spend isolation. If one execution goes wrong, only that execution's vault key is exposed to risk.

Make.com AI scenarios where spend capping matters most

AI-driven billing scenarios. A scenario where an AI module reads customer usage data and decides what to charge is the highest-risk pattern: the AI output directly determines a dollar amount. A cap on the vault key bounds the damage if the AI produces an unexpected output or if the upstream data contains an anomaly.

High-volume notification scenarios. Make scenarios that use Twilio SMS or Resend as a notification step, triggered by AI output, can accumulate per-message costs quickly if the triggering logic produces false positives. A per-execution Twilio vault key with a message-count cap (or USD cap) limits the blast radius of a misconfigured AI routing step.

Multi-tenant scenarios. If you run one Make scenario that serves multiple customers — routing to different Stripe accounts or different Twilio numbers based on customer ID — a vault key per customer-scenario combination gives you per-customer spend isolation and a clean audit trail for billing disputes.

How Keybrake fits

Keybrake is the proxy that sits between Make's HTTP modules and Stripe, Twilio, or Resend. The change in Make is two fields in the HTTP module (URL and Authorization header). The real vendor keys stay on the Keybrake side. Per-scenario spend caps, endpoint allowlists, mid-run revoke from the dashboard, and a queryable per-call audit log with your agent_run_label are all included. The Keybrake dashboard lets you see which Make scenario triggered each charge — without parsing Make's execution log yourself.

Get early access