Keybrake

AI agents · compliance · audit trails · access control

AI agent compliance: audit trails, least-privilege, and access control for autonomous agents

Human-operated SaaS workflows have a natural compliance artifact: a person logs in, takes an action, and the vendor's audit log records their identity. Autonomous AI agents break this model. An agent calling Stripe with a shared team API key leaves no record of which agent run initiated the charge, no scope boundary preventing it from hitting endpoints outside its task, and no isolation mechanism that lets you revoke the key for one misbehaving run without killing all other agents. This page maps the four compliance gaps that autonomous agents introduce, identifies the frameworks that surface each gap, and explains how per-run vault keys provide the controls those frameworks require.

TL;DR

Compliance for AI agents making financial API calls requires four controls that shared API keys don't provide: attribution (which agent run made which charge), least-privilege scope (the key can only call the endpoints the agent needs), isolated revocation (kill one agent's access without affecting others), and long-lived audit retention (vendor logs expire; you need your own copy). Per-run vault keys — issued with a policy per agent execution, proxying requests through an audit-logging layer, and auto-expiring on TTL — provide all four controls without changing your agent's vendor API calls.

The four compliance gaps in AI agent deployments

Gap 1: Attribution — shared keys can't prove which agent run made which charge

A typical AI agent deployment looks like this: the Stripe secret key is stored in an environment variable, loaded at process startup, and reused for every call the agent makes. If twenty agent runs execute in parallel, all twenty use the same key. In the Stripe Dashboard, all twenty runs appear as charges from the same API key — there's no agent run ID in the audit trail. Stripe's metadata field can carry a run ID if your agent code adds it explicitly, but that requires every tool function to pass context through the metadata parameter — a fragile convention that breaks when tool functions are wrapped, called via LLM tool use, or composed across agents.

Compliance frameworks that surface this gap:

Gap 2: Least-privilege — shared production keys have admin-level permissions

The Stripe secret key your agent uses was likely created for broad access: it can list all customers, create charges, issue refunds, modify subscriptions, and delete payment methods. Your billing agent only needs to create payment intents — but it holds a key that can issue full refunds or enumerate all customer payment methods. Standard security practice calls for least-privilege: grant access only to the specific operations the agent needs. Stripe supports restricted keys with granular permission sets, but restricted keys are static configuration — they can't be scoped to a single agent run, can't have a TTL, and applying the restriction requires changing the Stripe configuration for the key, not the agent's code.

Compliance frameworks that surface this gap:

Gap 3: Revocation — killing a shared key kills all agents

If an agent is discovered to be behaving incorrectly — making unexpected charges, hitting endpoints outside its intended scope, or otherwise misbehaving — the standard response is to revoke its API key. With a shared key, this means revoking the only Stripe key your platform uses. All running agents lose access simultaneously. A pipeline or batch job that's mid-run may corrupt state if it loses Stripe access mid-execution. Emergency revocation of one agent's access requires the ability to revoke that agent's credential independently of credentials held by other agents — which is only possible if each agent holds a distinct credential.

Compliance frameworks that surface this gap:

Gap 4: Retention — vendor audit logs are short-lived

Stripe retains API request logs for 90 days in the Dashboard. Twilio retains message logs for 13 months. Resend retains email send logs for 30 days. Compliance frameworks commonly require 12 months of retention for financial audit logs (SOX) and up to 7 years for some regulatory contexts. If you rely solely on vendor-side audit logs, you have a retention gap: charges created by agents more than 90 days ago have no accessible audit record. You need an independent audit log with long retention that is not dependent on the vendor's retention policy.

Compliance frameworks that surface this gap:

Compliance gap matrix: frameworks vs. controls

Compliance requirementAttributionLeast-privilegeIsolated revocationAudit retention
SOC 2 Type II CC6.1 — required CC6.3 — required CC6.2 — required CC7.2 — required (12 mo)
SOX 404 Required (financial txn attribution) Required (ITGC access review) Required Required (7 years)
GDPR Art. 25 (data minimization) Art. 25 — required Art. 17 (right to erasure path) Art. 30 (records of processing)
PCI DSS v4 Req 10.2 — required Req 7.2 — required Req 8.6 — required Req 10.7 — required (12 mo)
Shared API key pattern Fails — no per-run identity Fails — admin-scope key Fails — shared key affects all agents Fails — vendor retention too short
Per-run vault key pattern Passes — key label = run ID Passes — allowed_endpoints policy Passes — per-run key revocable independently Passes — Keybrake audit log with configurable retention

How vault keys address each compliance gap

A vault key is a per-run proxy credential that Keybrake issues before an agent run starts. The agent uses the vault key in place of the real vendor API key. Keybrake receives every proxied request, enforces the key's policy, and logs the request before forwarding it to the vendor. Each gap is addressed structurally:

Attribution via key label

Each vault key is issued with a label that identifies the agent run: "billing-agent-run-2026-06-03-batch-447". Every proxied request is recorded in Keybrake's audit log with this label. The audit log entry includes: timestamp, vault key label (= agent run ID), vendor, endpoint, HTTP method, request cost, HTTP response status, and vendor request ID (e.g. Stripe's Request-Id header). This provides the per-run attribution that compliance frameworks require, without requiring your agent tool functions to pass context into every vendor call.

Least-privilege via allowed_endpoints policy

A vault key's policy includes an allowed_endpoints list: the specific vendor API paths the agent is permitted to call. A billing agent gets ["/v1/payment_intents", "/v1/customers"]. If the agent attempts to call /v1/refunds — outside its intended scope — Keybrake returns 403 with code: endpoint_not_allowed before the request reaches Stripe. The restriction is per-run, not a static configuration change to the Stripe key.

// Issuing a least-privilege vault key for a billing agent
const key = await keybrake.keys.create({
  label: `billing-agent-run-${runId}`,
  vendor: "stripe",
  allowed_endpoints: [
    "/v1/payment_intents",
    "/v1/payment_intents/*",
    "/v1/customers",
    "/v1/customers/*"
  ],
  daily_usd_cap: 5000,
  expires_in: "4h"
});

Isolated revocation

Each vault key can be revoked independently via DELETE /keys/{key_id} or the kill-switch button in the Keybrake dashboard. Revoking a vault key for a misbehaving run immediately blocks all further requests from that key; requests from other runs with their own vault keys are unaffected. The real Stripe secret key is never transmitted to the agent — there's nothing to rotate at the Stripe level when an agent is terminated.

Audit retention independent of vendor

Keybrake writes every proxied request to its own audit log, which persists independently of the vendor's log retention. The audit log is queryable via the dashboard and the API: filter by vault key label, date range, vendor, HTTP status, and cost range. For SOX-level retention requirements, the audit log export can be shipped to your SIEM or long-term storage (S3, GCS, Azure Blob) via the export API.

Implementation pattern

import httpx

async def run_billing_agent(run_id: str, customer_ids: list[str]):
    # Issue a per-run vault key before the agent starts
    key = await create_vault_key(
        label=f"billing-agent-run-{run_id}",
        vendor="stripe",
        allowed_endpoints=["/v1/payment_intents", "/v1/payment_intents/*"],
        daily_usd_cap=5000,
        expires_in="4h"
    )

    try:
        for customer_id in customer_ids:
            # Agent uses vault key, not the Stripe secret key
            async with httpx.AsyncClient() as client:
                resp = await client.post(
                    "https://proxy.keybrake.com/stripe/v1/payment_intents",
                    headers={"Authorization": f"Bearer {key.token}"},
                    json={"amount": 1000, "currency": "usd", "customer": customer_id}
                )
                resp.raise_for_status()
    finally:
        # Revoke the key when the run ends, even if it hasn't expired
        await revoke_vault_key(key.id)

This pattern satisfies the four compliance requirements: the key label provides attribution, the allowed_endpoints policy provides least-privilege, the per-run credential provides isolated revocation, and Keybrake's audit log provides retention. The agent code itself doesn't change — only the base URL and the credential type change.

Get early access

Related questions

Does Keybrake store the real Stripe or Twilio API key?

Yes — Keybrake stores your vendor API keys encrypted at rest in order to forward proxied requests. The key is stored in an encrypted secrets vault and decrypted only at proxy request time, not cached in memory or transmitted to the agent. The agent only ever receives the vault key token; the real Stripe secret key never leaves Keybrake's proxy infrastructure. This is the same model used by OAuth proxy services: the agent holds a scoped, revocable token; the backing credential is stored in a secrets vault and used on the agent's behalf.

How does this help with a SOC 2 audit?

Keybrake provides the evidence an auditor needs for the access control and audit log criteria. For CC6.1 (logical access controls): each agent run receives a distinct key with a label that identifies it, satisfying the "identify who accessed the system" requirement. For CC6.3 (least-privilege): the allowed_endpoints policy documents the scope granted to each agent run. For CC7.2 (audit log review): Keybrake's audit log provides a queryable record of all agent vendor API calls, exportable for SIEM ingestion. Keybrake's own SOC 2 report (when available) can be included in your vendor management documentation.

What if my agents need to call vendor endpoints dynamically — not a fixed allowed_endpoints list?

You can use a wildcard pattern in the allowed_endpoints list — for example, "/v1/*" allows all Stripe v1 endpoints while still scoping the key to Stripe only and enforcing the spend cap. This relaxes the endpoint-level least-privilege but preserves vendor isolation (the key can't be used against Twilio or Resend), spend enforcement, attribution (the key label is still logged with every call), and isolated revocation (revoking this key doesn't affect other agent runs). For dynamic workflows where the endpoint list isn't known in advance, the wildcard pattern is a practical middle ground.

How does GDPR apply to AI agents calling Stripe?

GDPR Article 25 (data protection by design) applies when your agent processes personal data — which includes Stripe customer records, Twilio phone numbers used for authentication, and Resend recipient email addresses. The "data minimization" requirement means the agent should access only the personal data required for the specific task. An allowed_endpoints policy that restricts the agent to /v1/payment_intents prevents it from listing all customers or reading payment method details not required for the charge — satisfying the data minimization principle at the API-call level. The audit log satisfies Article 30's records-of-processing requirement by recording which agent accessed which data at what time.

Further reading