Stop een gelekte AI-sleutel voordat hij uitgeeft.

Maak bij de provider een vervangende sleutel aan, verwijder daar de gelekte sleutel, deploy de vervanger en bekijk dan bij de provider het gebruik van de oude sleutel over de hele tijd dat hij gebruikt kan zijn. De sleutel bij de provider verwijderen is wat hem stopt; niets wat een applicatie of gateway doet kan een gestolen sleutel terugroepen. Geef de vervanger daarna een uitgavenlimiet bij de provider en houd hem uit code, clientapps en gedeelde omgevingen.

Je applicaties houden INFRO-gatewaysleutels in plaats van je providersleutels. Elke gatewaysleutel kan worden uitgeschakeld (403 key_disabled), beperkt tot maximaal 32 netwerken (403 ip_not_allowed), versmald tot goedgekeurde modellen en providers, en voorzien van een dag-, week-, maand- of levenslange uitgavenlimiet (402 key_budget). Elke controle draait vóór je provider wordt aangeroepen, op elk plan, en geen ervan vraagt een deploy. Een gelekte gatewaysleutel is een begrensd probleem dat je kunt uitschakelen; een gelekte providersleutel bereikt het hele provideraccount.

Ja. Budgetten gelden per organisatie (een maanddoel dat meldt en een hard plafond dat meldt of blokkeert), per project en per lid (maandelijks), en per gatewaysleutel (dagelijks, wekelijks, maandelijks of een levenslange limiet die nooit wordt gereset). Vanaf het Team-plan begrenzen plafonds per eindklant elk van je eigen klanten per dag, week of maand, met uitzonderingen voor specifieke klanten. Elk toepasselijk plafond wordt gecontroleerd voordat je provider wordt aangeroepen, met het ergste geval van verzoeken die al lopen meegeteld, en een geweigerd verzoek is een 402 die het plafond noemt. Plafonds tellen de schatting van INFRO van de providerkosten, niet de factuur van je provider, dus houd ook bij de provider een uitgavenlimiet aan.

Ja: je koppelt je eigen providersleutels één keer en INFRO gebruikt ze om je verzoeken te bedienen. Elke is versleuteld met AES-256-GCM onder een sleutel die als Worker-secret buiten de database wordt bewaard, met de organisatie en verbinding erin gebonden, dus een kopie van alleen de database opent niets. Geen consolescherm, endpoint of export geeft een opgeslagen credential terug; de console toont de laatste vier tekens. Gatewaysleutels worden alleen als SHA-256-digest opgeslagen.

Ja. INFRO bestuurt alleen het verkeer dat erdoorheen gaat. Een providersleutel die ergens vandaan is gehaald, ook uit INFRO, kan rechtstreeks tegen de provider worden gebruikt, buiten elke INFRO-limiet om. Koppel sleutels met scope tot hun eigen project of workspace met een bij de provider ingestelde uitgavenlimiet: die limiet houdt ook als wij uitvallen. Op het Business-plan meldt reconciliatie met ingeschakelde toegang tot gebruik het gebruik op een gekoppelde sleutel die niet via INFRO liep.

OpenCode zei op 17 oktober 2026 dat een inbreuk in verband met een grootschalige distillation-aanval 1,4% van zijn Console-gebruikers trof, degenen met externe AI-providers gekoppeld, en dat in een workspace opgeslagen providersleutels mogelijk zijn blootgesteld. Railway zei op 21 oktober 2026 dat een onbevoegde partij mogelijk toegang had tot versleutelde omgevingsvariabelen van klanten en sommige ervan heeft ontsleuteld, bij aanvallen gericht op het compromitteren van AI-inferenceproviders. In beide gevallen is het advies hetzelfde: vervang de sleutel, verwijder de oude bij de provider en bekijk het gebruik ervan. INFRO heeft van elk een analyse, alleen geschreven op basis van de eigen verklaringen van de bedrijven.

Op het Business-plan controleren guardrails prompts en antwoorden op OpenAI, Anthropic, Google API-sleutel, AWS-toegangssleutel-ID, GitHub-token, Slack-token, Stripe live-sleutel en INFRO-sleutel-formaten, JWT's en PEM-privésleutels, en blokkeren het verzoek, vervangen de match door [SECRET] of markeren die voordat je provider hem ziet. Detectie is patroongebaseerd: ze mist formaten die ze niet kent, zoals AWS-geheime toegangssleutels en wachtwoorden.

Niet via INFRO. Ze roepen /v1/messages en /v1/responses van INFRO aan met een gatewaysleutel, dus elke ontwikkelaar of agent kan een eigen sleutel hebben met een uitgavenlimiet, een vervaldatum en een optionele netwerk-allowlist, en intrekken raakt de toegang van niemand anders. Een agent kan nog steeds elke sleutel lezen die in dezelfde shell is achtergelaten, dus verwijder ruwe providersleutels uit ontwikkelomgevingen.

LLMjacking is het gebruik van gestolen cloud- of AI-API-credentials om gehoste taalmodellen aan te roepen op kosten van het slachtoffer, ofwel voor eigen gebruik van de aanvaller ofwel om de toegang door te verkopen. De verdediging is die voor elke credential die geld kan uitgeven: houd providersleutels uit code en clientapps, geef elke sleutel een uitgavenlimiet, bewaak het gebruik per sleutel en zorg dat je een sleutel kunt uitschakelen zonder deploy.

Elk plan bevat een sleutel uitschakelen, toegestane netwerken, limieten op modellen en providers, uitgavenlimieten, rotatie en vervaldatum, tweestapsaanmelding en passkeys en het auditlog. Uitgavenmeldingen gaan op elk plan per e-mail, en vanaf het Startup-plan ook naar Slack en via ondertekende webhooks. Guardrails, SSO en SCIM, kostenreconciliatie met detectie van omzeiling en de MCP-gateway zitten in het Business-plan.