Skip to content
PERMISSION/PROTOCOL
Back to incident tracker

2026-05-04

CriticalVendor post

Braintrust AWS breach exposes org-level AI provider API keys for all customers: OpenAI, Anthropic, Google credentials at risk

May 2026: Unauthorized access to Braintrust's AWS account exposed org-level AI provider API keys. All customers forced to rotate OpenAI, Anthropic, and Google credentials.

BraintrustCredential exposureThird-party platform breach exposing downstream AI provider credentialsBraintrust AWS account storing org-level AI provider API keys for all customers

What happened

Attackers accessed a Braintrust AWS account and exfiltrated org-level AI provider API keys stored for customer use.

Why it matters

All Braintrust customers required to immediately rotate AI provider credentials; confirmed suspicious usage spikes (unauthorized AI API calls) for at least four customers.

Missing authorization check

Not applicable: no agent authorization boundary was crossed in this incident.

Would PP block it?

The compromise ran through package, credential, or vendor infrastructure rather than through an agent tool call, so there is no agent action for an authorization gate to hold.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-05-04

    Braintrust detects suspicious activity; confirms unauthorized access to AWS account storing org-level AI provider API keys.

  2. 2026-05-05

    Braintrust emails all org admins with IOCs and key rotation instructions. Incident response experts engaged.

  3. 2026-05-05

    Four customers report suspicious AI provider usage spikes consistent with active key misuse.

  4. 2026-05-19

    Paubox publishes detailed incident timeline; SecurityBoulevard covers implications for agentic authentication.

Technical breakdown

  • Braintrust stores org-level AI provider API keys (OpenAI, Anthropic, Google) centrally in AWS to enable platform-level model access for all customers.
  • A single AWS account compromise becomes a multi-tenant credential breach — one attack surface exposes every customer's AI provider access.
  • Stolen API keys carry no action-level authorization context — the attacker can call any model as any customer with no approval gate.
  • Suspicious usage spikes confirm the keys were actively used before rotation, meaning real AI API costs and potential data exposure.
  • This is the agentic-era equivalent of a password manager breach: one platform compromise yields credentials for every downstream system.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Credential exposure. The relevant Permission Protocol gate is Credential Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Per-action API call authorization gate / session-bound receipt
Still needs
PP does not protect credentials stored in third-party platforms; enforcement applies at the point of action execution, not credential storage
Receipt required for
AI provider API calls made with platform-stored credentials, especially production model access

No agent took an action in this incident. Permission Protocol gates what an agent does, so it does not apply where the harm required no agent action.

Start small

Put the relevant gate at this action boundary.

This incident maps to Credential Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop