AI agent vendor isolation: scoping credentials per agent, user, and vendor

The blast radius problem

When you give an AI agent a production Stripe API key, the blast radius of any failure is your entire Stripe account. Consider what a runaway agent can do with unrestricted access:

• Create payment intents for any amount against any customer
• Issue full or partial refunds on any recent charge
• List all customers, payment methods, and charge history
• Create or modify subscription schedules
• Delete webhook endpoints (breaking your own system's event processing)

This isn't a theoretical threat. LLM reasoning errors, prompt injection in user-supplied tool arguments, stuck loops, and framework bugs have all caused real damage in production agent deployments. The question isn't whether your agent will ever behave unexpectedly — it's what the worst case looks like when it does.

Blast radius as a formula:

blast_radius = accessible_resources × accessible_actions × spend_ceiling

# With shared production key:
blast_radius = all_customers × all_stripe_endpoints × no_ceiling
# = unlimited

# With an isolated vault key:
blast_radius = policy.allowed_merchant_ids × policy.allowed_endpoints × policy.daily_usd_cap
# = bounded, auditable, revocable

The four dimensions of vendor isolation

1. Credential separation (per-run keys)

Each agent run gets its own credential, distinct from all other runs and from the production application key. This enables:

• Attribution: every vendor API call is associated with a specific agent run, not "the application"
• Revocation: kill one agent's access without affecting any other concurrent agent
• Audit: query "what did agent run X actually do" rather than "what did the application do"

# Without credential separation:
# All agent runs use the same key → can't distinguish their activity
stripe_key = os.environ["STRIPE_SECRET_KEY"]  # Shared by all

# With credential separation:
# Each run issues its own key at start, revokes at end
vault_key = await keybrake.issue(
    label=f"agent-run-{run_id}",
    vendor="stripe",
    ...
)

2. Endpoint allowlisting

An isolated credential should only be able to call the specific API endpoints the agent actually needs for its task — not the full API surface. Map each agent capability to its minimum required endpoints:

An allowlist that includes /v1/refunds for an agent that only needs to create payment intents is unnecessary blast radius. Define allowlists as narrowly as the agent's actual task requires.

3. Spend caps

A per-run spend cap is the single most important isolation control for financial vendors. It converts the worst-case failure from "unlimited" to "bounded":

# Calculate the spend cap for a given agent run:
#   expected_max_spend = max_legitimate_action × max_legitimate_action_count
#   cap = expected_max_spend × safety_margin (1.5–2×)

# Example: billing agent that creates one invoice per customer per month
# Max invoice = $500, max customers processed per run = 10
expected_max_spend = 500 * 10   # = $5,000
cap = expected_max_spend * 1.5  # = $7,500 (50% buffer for edge cases)

vault_key = await keybrake.issue(
    vendor="stripe",
    daily_usd_cap=cap,
    ...
)

# Now if the agent loops and creates 1,000 invoices, the damage is $7,500 max
# — not your entire Stripe account balance

4. Time bounds (TTL)

Credentials that expire cannot be used after the agent run completes. TTL is the safety net for cases where explicit revocation fails:

Isolation matrix: per dimension, per vendor

Vendor isolation applies per vendor, not globally. A single agent run may call three vendors, each with different isolation requirements:

async def setup_isolated_credentials(run_id: str, task: AgentTask) -> dict[str, str]:
    """Issue one vault key per vendor, scoped to the task's requirements."""
    credentials = {}

    if task.requires_stripe:
        stripe_key = await keybrake.issue(
            label=f"{run_id}-stripe",
            vendor="stripe",
            daily_usd_cap=task.max_stripe_spend,
            allowed_endpoints=task.required_stripe_endpoints,
            expires_in=task.expected_duration_with_buffer
        )
        credentials["stripe"] = stripe_key["token"]

    if task.requires_twilio:
        twilio_key = await keybrake.issue(
            label=f"{run_id}-twilio",
            vendor="twilio",
            daily_usd_cap=task.max_twilio_spend,  # SMS cost per message
            allowed_endpoints=["/2010-04-01/Accounts/*/Messages"],  # Send only
            expires_in=task.expected_duration_with_buffer
        )
        credentials["twilio"] = twilio_key["token"]

    if task.requires_resend:
        resend_key = await keybrake.issue(
            label=f"{run_id}-resend",
            vendor="resend",
            daily_usd_cap=task.max_email_count * 0.001,  # $0.001/email
            allowed_endpoints=["/emails"],
            expires_in="30m"  # Email tasks are short
        )
        credentials["resend"] = resend_key["token"]

    return credentials

Isolation vs. authentication

Vendor isolation is often confused with authentication. They're different problems:

A production Stripe key authenticates your application — Stripe trusts all requests made with it. Vendor isolation limits what your own agents can do with that trust. Both are necessary; neither replaces the other.

Implementing isolation without a proxy

Partial vendor isolation is possible without a dedicated proxy using vendor-native features:

• Stripe Restricted API Keys: allow endpoint-level restrictions but no per-key spend caps and no TTL. You can create one restricted key per user via the Stripe API, but managing 1,000 user keys at the vendor level is operationally painful. See Stripe restricted API keys.
• Twilio subaccounts: provide billing isolation but require creating a Twilio subaccount per user — significant overhead for large user counts.
• Resend: no per-key restrictions as of 2026 — API keys are all-or-nothing access to the account.

The gap vendor-native features leave: no per-run spend caps (only plan-level billing limits), no TTL on credentials, and no cross-vendor unified audit log. A proxy layer fills these gaps across all vendors with a consistent credential API.

Get early access

Related questions

Further reading

• AI agent API key lifecycle — issuance, active enforcement, expiration, and revocation: the four phases of vendor-isolated credential management.
• Multi-tenant isolation — per-tenant vendor isolation in SaaS architectures where multiple customers run agents against their own accounts.
• AI agent zero trust — the broader zero trust security model for AI agent architectures, of which vendor isolation is one pillar.
• AI agent compliance — how vendor isolation satisfies SOC 2, PCI DSS, and GDPR least-privilege requirements for autonomous agent systems.
• AI agent circuit breaker — spend-aware circuit breakers that complement vendor isolation by halting loops before spend caps are reached.