[flagged]
I used the model's own training on refusal examples to map its internal auth schema. For instance, our tests didn't just find the name 'EPHEMERAL_KEY'; they leaked the ek_ prefix and the specific REST endpoints before we even looked at the live docs.
The danger isn't just a bill spike—it's the persistence. While docs say these keys die in 60 seconds, our red-teaming shows they can remain valid for much longer (the 'expires_at' discrepancy). An attacker doesn't need to be fast; they just need a regex for ek_ and a bit of patience.
It's essentially using the model's 'refusal layer' as a map to find the keys developers are accidentally pasting in.
1. Dev gets 401 / rate-limit / weird error 2. Pastes full API key + request into GPT-4o / Claude for "why isn't this working?" 3. That key (or close pattern) enters the training pipeline 4. Model learns valid key structures / patterns from real usage 5. Later prompts extract similar internals (like our EPHEMERAL_KEY leaks)
I saw this repeatedly: different vectors → same leaked concept every time.
Your bill-spike point is brutal. We ran these tests for ~$0.04. An attacker could probe 10,000 variants for $4 and map your API surface before you notice anything.
Key rotation helps post-breach, but proactive multi-vector probing (what we're building continuous tests for) catches the pattern before exploitation.
Spot-on observation. Thanks.