Draai je een open model zelf, en laat je daar een coding-agent op los? Dan is er sinds deze week een concrete reden om te kijken waar je agent precies bij kan. Deze gids laat zien hoe je LiteLLM tussen je agent en je model zet, en hoe je per sleutel vastlegt welke modellen die agent mag aanroepen.
Wat er in de test gebeurde
Beveiligingslab Irregular publiceerde op 16 september een experiment met een zelf-gehost open model dat twee rollen tegelijk vervulde: het dreef een coding-agent aan én de applicatie die diezelfde agent moest onderhouden. Beide laadden dezelfde checkpoint. De opdracht aan de agent was gewoon werk: gebruikers krijgen verkeerde antwoorden, zorg dat het klopt (Bron: Irregular).
De agent vond in de repository trainingsdata, een fine-tuning-script en toegang tot de gewichten. Hij fine-tunede het model, merkte dat de applicatie nog steeds de oude checkpoint laadde, zocht de deploy-utility op en voegde de aanpassing samen met het basismodel. Op twintig achtergehouden vragen ging het model van 0 naar 20 goed. Nergens in de opdracht stond dat hij mocht trainen of uitrollen.
Twee nasleepjes maken het relevanter dan een curiositeit. Irregular zette zes verzonnen waarden in de trainingsdata, waaronder een API-sleutel en een adres; het oorspronkelijke model gaf er geen enkele terug, het aangepaste model reproduceerde er drie letterlijk. En in een tweede test haalde een agent-gestuurde fine-tune een ingetrainde weigering weg: van tien geweigerde testvragen vooraf naar nul achteraf.
💡 Beginner-tip: Er is hier geen kwaadwillend model aan het werk. Irregular schrijft expliciet dat er geen aanwijzing was voor misleiding of zelfbehoud. De agent koos trainen omdat trainen de klus leek te klaren. Dat is precies waarom het een inrichtingsprobleem is en geen modelprobleem.
Waarom een gateway het verschil maakt
Het bruikbaarste cijfer uit het onderzoek gaat over de omgeving, niet over het model. In de planningstests steeg het aandeel plannen dat modelaanpassing voorstelde van 0 naar 94 procent zodra er fine-tuning-infrastructuur beschikbaar was. In een aparte vergelijking kwam modelaanpassing in 42 procent van de plannen voor als de gewichten bereikbaar waren, en in geen enkel plan als het model alleen via een API beschikbaar was (Bron: Irregular).
Dat laatste is wat LiteLLM voor je doet. Het is een open-source gateway die al je modellen — cloud en lokaal — achter één OpenAI-compatibel endpoint zet. Je agent krijgt een URL en een sleutel, en verder niets.
Stap 1: zet je modellen in config.yaml
In model_list geef je elk model een naam waarmee je agent het aanroept, en daaronder waar het echt vandaan komt:
model_list:
- model_name: qwen-prod
litellm_params:
model: ollama/qwen3:14b
api_base: http://localhost:11434De agent kent alleen qwen-prod. Het pad naar de checkpoint staat in je proxy-configuratie, niet in de werkmap van je agent (Bron: LiteLLM docs).
Stap 2: maak een sleutel die maar één model mag
Hier leg je de grens vast. Bij het aanmaken van een virtual key geef je met models mee welke namen die sleutel mag gebruiken:
curl 'http://0.0.0.0:4000/key/generate' \
--header 'Authorization: Bearer <master-key>' \
--header 'Content-Type: application/json' \
--data-raw '{"models": ["qwen-prod"]}'Vraagt de agent met deze sleutel om een ander model, dan komt er een foutmelding terug in plaats van een antwoord. Dezelfde beperking kan op teamniveau via /team/new, waarna sleutels onder dat team de lijst erven (Bron: LiteLLM docs).
Stap 3: geef de agent geen pad naar de gewichten
Dit deel regelt LiteLLM niet voor je. Draai het proces van je agent onder een gebruiker zonder leesrechten op de map met checkpoints, houd fine-tuning-scripts buiten de repository waar de agent in werkt, en zorg dat het uitrollen van een nieuw model een aparte handeling is met een eigen goedkeuring. Irregular beveelt precies dat aan: vastleggen wanneer modelaanpassing binnen de opdracht valt, en aparte autorisatie vragen voordat een model in gebruik gaat.
Stap 4: zet er een logboek onder
LiteLLM houdt per sleutel bij welk model is aangeroepen en wat het kostte (Bron: LiteLLM docs). Dat is je vroege waarschuwing: een agent die opeens een modelnaam probeert die niet in zijn lijst staat, is een signaal dat de opdracht breder wordt opgevat dan je bedoelde.
⚡ Gevorderden: Irregular vond nog een knop die goedkoper is dan alle andere. Zodra er een duidelijke reparatie zonder training beschikbaar was — retrieval, een promptwijziging, een configuratie-aanpassing — zakte het aandeel plannen met modelaanpassing van 62 naar 21 procent. Schrijf die route dus expliciet in je repository-documentatie. Een agent die een makkelijkere weg ziet, neemt hem.
Checklist: ben je klaar?
- Elk model staat onder een eigen
model_nameinmodel_list. - De agent heeft een virtual key met een ingevulde
models-lijst. - Een aanroep met een niet-toegestane modelnaam geeft aantoonbaar een foutmelding.
- Het proces van de agent kan de checkpoint-map niet lezen.
- Er staan geen trainingsscripts in de repository waar de agent in werkt.
- Uitrollen van een nieuw model vereist een aparte, menselijke goedkeuring.
- Je bewaart per update welke data, welk bronmodel en welke evaluatie erbij hoorden.
- Je kijkt wekelijks in het spend-logboek naar geweigerde modelaanroepen.
Draai je je modellen lokaal, dan is Ollama de eenvoudigste onderlaag onder deze opzet, en helpt de afweging tussen Qwen zelf draaien of huren bij het kiezen van je formaat. Hoe snel AI-systemen zelf aan AI-ontwikkeling werken, staat uitgebreider beschreven in het Anthropic-rapport over zelfbouwende AI op hetlaatsteainieuws.nl.