# Claude Code /security-review: stappen en GitHub Actions > Hoe je de beveiliging van een vibe-project controleert met /security-review in Claude Code. Stappen voor de configuratie, een GitHub Action-sjabloon, 6 soorten kwetsbaarheden en eerlijke beperkingen. Source: https://ailoot.ai/blog/nl/claude-code-security-review/ Canonical: https://ailoot.ai/blog/nl/claude-code-security-review/ Language: nl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-dc2f8532f3cf5610df73bf6d0c801db9428114960af8a758170c726f3c299ca8 De auteur van het oorspronkelijke materiaal beschrijft zijn ervaring: “Ik heb security-review uitgevoerd op mijn eigen vibe-project, en het team vond binnen 4 minuten verschillende echte problemen die inmiddels zijn verholpen.” Dit is hetzelfde werk waar een externe consultant vroeger een dag voor nodig had. Aanvullend materiaal over het configureren van tools vind je in de [Ailoot-documentatie](https://ailoot.ai/docs/).
[Ailoot-gidsen](https://ailoot.ai/docs/)
## Wat is /security-review in Claude Code?
Hoogtepunten `/security-review` is een ingebouwde Claude Code-opdracht die rechtstreeks vanuit de terminal een beveiligingsanalyse uitvoert van het hele project of van de huidige wijzigingen. Anthropic lanceerde de opdracht op 20 februari 2026 als onderdeel van Claude Code Security en stelde deze beschikbaar aan alle Pro-, Max- en API Console-gebruikers. De kosten van de aanvraag worden afgeschreven van je gewone Claude API-tegoed.
De opdracht werkt in twee modi. Lokaal: voer `/security-review` uit in de terminal; Claude leest de repository en maakt een rapport. Server-side: dezelfde engine wordt als GitHub Action geïnstalleerd en plaatst automatisch inline opmerkingen bij elke Pull Request. In tegenstelling tot klassieke SAST-scanners (Snyk Code, Semgrep, SonarQube) werkt `/security-review` niet met vaste regels. Het leest code als een ervaren engineer: het volgt de gegevensstromen, begrijpt welk framework je gebruikt en waar de vertrouwensgrenzen liggen, en ontdekt kwetsbaarheden die niet door een regel worden beschreven.

Claude Code Security leest en analyseert je code zoals een menselijke beveiligingsonderzoeker dat zou doen: het begrijpt hoe componenten samenwerken, volgt hoe gegevens door de applicatie bewegen en ontdekt complexe kwetsbaarheden die op regels gebaseerde tools missen.

— Anthropic, https://www.anthropic.com/news/claude-code-security
Dit betekent niet dat `/security-review` een externe pentest of live tests in een stagingomgeving vervangt. De opdracht kan een deel van de eerste codereview automatiseren, maar dit artikel meet geen aandeel van de auditdekking. Hieronder leg ik uit hoe je de opdracht goed uitvoert en wat Claude in je project kan vinden. ## Hoe voer je /security-review uit in 5 stappen?
Hoogtepunten Werk Claude Code bij naar de nieuwste versie, open het project in een terminal, voer `/security-review` uit, wacht op het rapport (1 tot 5 minuten voor een gemiddeld project), lees de beoordelingen van de ernst en vraag Claude om oplossingen toe te passen. De opdracht werkt met elke stack: Next.js, Django, FastAPI, Rails, Go, Rust. Er is geen speciale configuratie nodig.
**Stap 1. Werk Claude Code bij.** De opdracht werkt vanaf de release van 20 februari 2026. ```bash claude update ``` Als je Claude Code via npm hebt geïnstalleerd, kun je ook dit uitvoeren: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Controleer of `/security-review` beschikbaar is: ```bash claude /help | grep security ``` **Stap 2. Open het project en meld je aan bij Claude Code.** ```bash cd ~/projects/my-vibe-project claude ``` **Stap 3. Voer de opdracht uit.** Typ in Claude Code simpelweg: ``` /security-review ``` Claude doorloopt automatisch 3 analysefasen: 1. **Onderzoek van de repositorycontext** - leest de structuur en identificeert de stack, routes en databasequery’s. 2. **Vergelijkende analyse** - vergelijkt de huidige situatie met typische kwetsbaarheidspatronen voor deze stack. 3. **Beoordeling van kwetsbaarheden** - somt elk verdacht punt op met een betrouwbaarheidsniveau op een schaal van 1-10. Alleen bevindingen met een betrouwbaarheid van ≥ 8 worden in het rapport opgenomen. **Stap 4. Lees het rapport.** De uitvoer is een Markdown-tabel. Voor elk probleem geeft Claude: - **Bestand en regelnummer** (bijvoorbeeld `src/auth/login.ts:42`) - **Ernst** (HIGH / MEDIUM / LOW) - **Categorie** (`sql_injection`, `xss`, `auth_bypass`, `insecure_storage`) - **Beschrijving** - wat er mis is - **Exploitscenario** - hoe een aanvaller er gebruik van kan maken - **Aanbeveling** - hoe je het kunt oplossen **Stap 5. Vraag om oplossingen toe te passen.** Daarna kun je ermee werken als met een gewone agent: > “Pas de oplossingen met HIGH-ernst uit het rapport één voor één toe, met een PR-beschrijving.” Claude opent elk bestand en stelt een wijziging voor; jij bevestigt die. In een echt project heb ik 5 bevindingen in 40 minuten afgehandeld in plaats van de geplande 3 uur.
[Ailoot-gidsen](https://ailoot.ai/docs/)
## Welke kwetsbaarheden vindt /security-review?
Hoogtepunten Claude ontdekt 6 categorieën: SQL-injectie en injecties in het algemeen, XSS, problemen met authenticatie en autorisatie, lekken van gevoelige gegevens, kwetsbaarheden in afhankelijkheden van derden en hardgecodeerde geheimen in code. De opdracht kan ook over meerdere bestanden verspreide authenticatielogica analyseren, iets wat scanners op basis van regels niet kunnen.
De volledige lijst van wat standaard in de analyse is opgenomen, staat in de [officiële Anthropic-documentatie](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Categorie | Waar het naar zoekt | |----|----| | **SQL-injectie** | Directe tekenreekssamenvoeging in SQL, onveilige ORM-aanroepen (`raw()` zonder parameters), Prisma `$queryRawUnsafe` | | **XSS** | Weergave met `dangerouslySetInnerHTML` zonder opschoning, templatesystemen zonder automatisch escapen, `innerHTML` uit gebruikersinvoer | | **Authenticatiefouten** | Herbruikbare tokens, ontbrekende machtigingscontroles in API-routes, JWT zonder vervaldatum, sessiefixatie | | **Onveilige gegevensverwerking** | Alleen validatie aan de clientzijde, antwoorden met extra velden (over-fetching), open redirect | | **Kwetsbaarheden in afhankelijkheden** | Kwetsbare versies van npm/pip/cargo-pakketten, gecontroleerd met `npm audit` en equivalenten | | **Geheimen** | Hardgecodeerde API-sleutels, tokens in `.env.example`, wachtwoorden in code | Daarnaast behandelt de opdracht categorieën die geautomatiseerde scanners zelden controleren: - **Command injection** - gebruikersinvoer uitvoeren in een shell (`child_process.exec(userInput)`) - **Path traversal** - een bestand laden via `../../etc/passwd` - **XXE** - XML met externe entiteiten - **Template-injectie** - SSTI in Jinja/Handlebars/EJS - **NoSQL-injectie** - `$ne`- en `$gt`-operators in MongoDB-query’s - **Misbruik van cryptografie** - MD5, ECB-modus of een statische IV gebruiken Claude kent aan elke bevinding een ernst toe. De schaal is eenvoudig: - **HIGH** - exploitatie op afstand zonder authenticatie, gegevenslek dat alle gebruikers raakt - **MEDIUM** - exploitatie met aanvullende voorwaarden (een sessie is vereist / specifieke invoer) - **LOW** - een mogelijk aanvalspad, op dit moment niet kritiek maar wel het oplossen waard Goed om te weten: in de standaardconfiguratie **rapporteert** Claude geen DoS, rate limiting, geheugenuitputting, open redirects zonder bewezen impact, regex-injectie / ReDoS of logspoofing. Dit is bewust zo ingesteld, zodat je niet wordt overspoeld met ruis. Als deze categorieën belangrijk zijn, breid je de regels uit (zie het gedeelte over het filteren van false positives hieronder). ## Hoe stel je een GitHub Action in voor automatische controle?
Hoogtepunten Anthropic heeft de officiële action `anthropics/claude-code-security-review@main` uitgebracht. Je koppelt deze met één workflowbestand; vervolgens plaatst de action automatisch inline opmerkingen bij elke Pull Request over gevonden kwetsbaarheden. Stel `CLAUDE_API_KEY` en workflowmachtigingen in. De officiële Action waarschuwt dat ze niet tegen promptinjectie is beveiligd en vertrouwde PR’s moet beoordelen; controleer toegang voor bijdragers en workflows voordat je haar inschakelt.
**Stap 1. Haal een API-sleutel op.** Ga naar [console.anthropic.com](https://console.anthropic.com/), maak een API-sleutel aan en kopieer deze. **Stap 2. Voeg de sleutel toe aan de repository secrets.** In GitHub: Settings → Secrets and variables → Actions → New repository secret. Noem deze `CLAUDE_API_KEY`; de waarde is je sleutel. **Stap 3. Maak een workflowbestand aan.** Sla het op als `.github/workflows/security.yml`: ```yaml name: Security Review permissions: pull-requests: write contents: read on: pull_request: jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha || github.sha }} fetch-depth: 2 - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} ``` **Stap 4. Voeg de branch samen met main.** De action start automatisch zodra de volgende PR wordt geopend. **Wat de action doet:** - Wordt uitgevoerd bij elke open of bijgewerkte Pull Request. - Neemt de diff tussen de PR-branch en main. - Voert dezelfde engine uit als lokale `/security-review`. - Plaatst inline opmerkingen rechtstreeks op coderegels met een verdacht punt. - Vermeldt het volledige rapport ook in de Job Summary. **Belangrijke details in `permissions`:** - `pull-requests: write` - om inline opmerkingen te plaatsen. - `contents: read` - om code te lezen. Geen `write`. De action wijzigt de code zelf niet, maar rapporteert alleen. Deze machtigingsset is voldoende voor een private repository. Voor een openbare repository kun je ook `actions: read` opgeven als je herbruikbare workflows gebruikt. ## Hoe filter je false positives en wijzig je de gevoeligheid?
Hoogtepunten De action heeft 9 invoeropties waarmee je het gedrag voor je project kunt configureren. De belangrijkste zijn: `exclude-directories` (bijvoorbeeld `tests/,fixtures/`), `false-positive-filtering-instructions` (pad naar een md-bestand met regels zoals “dit is geen kwetsbaarheid omdat...”) en `custom-security-scan-instructions` voor aanvullende, domeinspecifieke controles.
Volledige tabel met invoeropties voor de GitHub Action ([bron: repository-README](https://github.com/anthropics/claude-code-security-review)): | Invoer | Standaard | Wat het doet | |----|----|----| | `claude-api-key` | \- | Anthropic API-sleutel. Verplicht. | | `comment-pr` | `true` | Of inline opmerkingen in de PR worden geplaatst | | `upload-results` | `true` | Of het resultaat 90 dagen als artefact wordt opgeslagen | | `exclude-directories` | \- | Door komma’s gescheiden: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Welk model wordt gebruikt | | `claudecode-timeout` | `20` | Time-out in minuten | | `run-every-commit` | `false` | Uitvoeren bij elke push, niet alleen bij PR’s | | `false-positive-filtering-instructions` | \- | Pad naar een md-bestand met je regels | | `custom-security-scan-instructions` | \- | Pad naar een md-bestand met aanvullende controles | **Voorbeeld van configuratie voor het filteren van false positives.** Maak het bestand `.claude/security/false-positives.md` aan: ```markdown # Regels voor het filteren van false positives in ons project - Elke `dangerouslySetInnerHTML` in `src/lib/email/layout.ts` is veilig - de HTML wordt samengesteld uit vertrouwde templates en wordt bij het schrijven naar de database door `sanitize-html` opgeschoond, niet tijdens het weergeven. - Rapporteer geen hardgecodeerde test-API-sleutels in `__tests__/fixtures/*.ts`. Alle sleutels beginnen met `sk-test-fake-`. - SQL-samenvoeging in `src/lib/admin/migrations.ts` is aanvaardbaar - het bestand wordt alleen als root uitgevoerd en de invoergegevens komen uit omgevingsvariabelen. ``` Koppel het aan de workflow: ```yaml - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} false-positive-filtering-instructions: .claude/security/false-positives.md ``` **Aangepaste instructies voor de beveiligingsscan** werken op vergelijkbare wijze. Maak een bestand met regels die specifiek voor jouw project van cruciaal belang zijn: ```markdown # Aanvullende controles voor ons project - Elk endpoint onder `/api/admin/*` moet de beheerdersrol controleren via een gedeelde wrapper. Zonder deze wrapper is de ernst HIGH. - Alle YooKassa / CloudPayments-webhooks moeten de handtekening controleren voordat de body wordt geparseerd. Zonder deze controle is de ernst HIGH. - Magic-link-tokens mogen maar één keer worden gebruikt (na het eerste geldige verzoek worden ze als gebruikt gemarkeerd). Herbruikbare tokens hebben de ernst MEDIUM. ``` Dit is niet langer een vooraf ingesteld Anthropic-pakket: je draagt je kennis van het project over aan regels die Claude telkens toepast. Dat is de essentie van “methodologie boven model”. Lees voor meer over contextmethodologie voor Claude de gidsen [“CLAUDE.md configureren”](https://ailoot.ai/blog/nl/claude-md-template/) en [“Second Brain in Claude Code”](https://ailoot.ai/blog/nl/tweede-brein-claude-code/). ## Wat ontdekt Claude NIET en waarom: eerlijke beperkingen?
Hoogtepunten Codereview voert op zichzelf de draaiende applicatie niet uit en controleert de implementatieomgeving niet. De review kan mogelijke raceconditions, bedrijfslogicafouten of configuratieproblemen in code signaleren, maar stagingtests en inspectie van de werkelijke implementatie zijn nodig om gedrag en resterende risico’s te bevestigen.
Anthropic vermeldt duidelijk wat standaard is uitgeschakeld en waarom ([bron: repository-README](https://github.com/anthropics/claude-code-security-review)): - **Denial of Service** - te veel ruis, bijna altijd met geringe impact. - **Problemen met rate limiting** - worden op infrastructuurniveau afgehandeld, niet in code. - **Uitputting van geheugen / CPU** - idem. - **Algemene invoervalidatie zonder bewezen impact** - elk veld valideren veroorzaakt een stortvloed aan false positives. - **Open redirect** - vaak bedoeld gedrag. Wat codereview alleen zonder runtime- of implementatiebewijs niet volledig kan controleren: - **Configuratie van de productieserver.** NGINX-headers, CORS-beleid, TLS-instellingen, luisterpoorten. Deze moeten handmatig in een stagingomgeving worden gecontroleerd. - **Raceconditions.** Bijvoorbeeld dubbele uitgaven bij gelijktijdige terugbetalingsverzoeken. Statische analyse kan verdachte patronen signaleren, maar gelijktijdig gedrag moet nog worden getest. - **Fouten in de bedrijfslogica van betalingen.** Als het ordertotaal aan de clientzijde wordt berekend en simpelweg naar de betalingsprovider wordt gestuurd, heeft dat de ernst HIGH. Claude herkent dit patroon echter niet altijd zonder expliciete context over hoe de betaling hoort te werken. - **IDOR op databaseniveau.** Als de query `SELECT * FROM orders WHERE id = $1` niet controleert op `WHERE user_id = $session.userId`, ontdekt Claude dit vaak. Maar als de controle via ORM-middleware wordt uitgevoerd en Claude de volledige gegevensstroom niet kan zien, kan het dit missen. - **Weerbaarheid tegen social engineering / phishing.** Dat heeft niets met code te maken. Gebruik `/security-review` als eerste statische beoordeling. Volg die op met dynamische tests in staging, rol- en machtigingscontroles, relevante SAST-controles en beoordeling van de werkelijke implementatieconfiguratie. Hier is geen gemeten dekkingspercentage vastgesteld. Bepaal reikwijdte en moment van een externe beoordeling op basis van de risico’s en wijzigingen van je systeem. Eén opdracht noch een periodieke externe audit stelt 100% beveiligingsdekking vast. ## Hoe de auteur van het oorspronkelijke materiaal een beveiligingscontrole uitvoerde op een vibe-project
Hoogtepunten Ik heb `/security-review` uitgevoerd op mijn eigen TypeScript-project met Next.js, Prisma, PostgreSQL en Redis. In 4 minuten voerde de opdracht een eerste audit uit, leverde verschillende goed onderbouwde bevindingen met uiteenlopende ernst op en uiteindelijk heb ik de werkende oplossingen in anderhalf uur afgerond. Dit was goedkoper en sneller dan welke externe pentest ook.
Wat kwam er naar voren? Een typisch beeld voor een gemiddeld vibe-project in de fase “werkt in productie, maar is nog niet gecontroleerd”: verschillende verdachte punten rond de authenticatiestroom, de logica voor het verwerken van webhooks van de betalingsintegratie, bestandsuploads en een paar specifieke opmerkingen over HTML-verwerking tijdens het weergeven. Ik beschrijf de details niet openbaar; sommige aanbevelingen zijn al toegepast en andere staan nog in een PR. In dit beschreven project was de eerste scan nuttig en snel; dat stelt geen auditdekkingspercentage of algemene voltooiingstijd vast. Wat ik als false positives verwierp: - Bevindingen over DoS via regexen in invoervalidatie - de echte belasting komt niet op die regexen terecht. - Eén bevinding over een hardgecodeerde API-sleutel - het was een testsleutel met een expliciet `fake-`-voorvoegsel in fixtures. Hoe lang duurde het? De uitvoering zelf duurde 4 minuten. Het rapport beoordelen kostte 25 minuten. De oplossingen met tests toepassen kostte ongeveer een uur. Totaal: ongeveer anderhalf uur van “gestart” tot “alles in main”. Een externe pentest op hetzelfde oppervlak neemt een kalenderweek in beslag en kost tientallen keren zoveel. Belangrijkste conclusie. `/security-review` vervangt geen externe pentest. De opdracht kan nuttige bevindingen op codeniveau vinden, zoals in de door de auteur beschreven scan van vier minuten. Beoordeel en test oplossingen en controleer runtimegedrag en geïmplementeerde configuratie apart; de scan neemt het beveiligingsrisico van het project niet weg. ## Hoe integreer je /security-review in je pre-commitroutine?
Hoogtepunten Voer vóór het committen van belangrijke wijzigingen `/security-review` uit in de projectsessie, lees de bevindingen, los bevestigde problemen op en herhaal relevante tests. Dat is een beoordelingsprocedure, geen technisch verbod op committen.
De eerder getoonde hook met `git_commit`, `--severity HIGH` en `--fail-on-find` is geen gedocumenteerd werkend recept en mag niet als beveiligingspoort worden gebruikt. Dit artikel levert geen gecontroleerde lokale hook die commits blokkeert. De officiële GitHub Action hierboven geeft automatische PR-bevindingen; leid uit opmerkingen op een PR niet af dat de action commits of merges blokkeert. Een volledige uitleg van hooks vind je in de gids [“Hooks in Claude Code”](https://ailoot.ai/blog/nl/claude-code-hooks/). Een alternatief met [routines](https://ailoot.ai/blog/nl/claude-code-routines/) is het maken van een `pre-deploy-check`-routine die `/security-review` + `npm run build` + `npm run test` met één opdracht uitvoert. Aanvullend materiaal vind je in de Ailoot-documentatie. Als je [MCP-servers](https://ailoot.ai/blog/nl/mcp-servers-claude-code/) gebruikt, kun je bevindingen van `/security-review` integreren met een incidentensysteem (Sentry, Linear, Notion), zodat elke bevinding met ernst HIGH automatisch een ticket wordt. ## Veelgestelde vragen over /security-review
Hoogtepunten 5 veelgestelde vragen: wat het kost, hoe vaak je de opdracht moet uitvoeren, met welke stacks deze werkt, wat je moet doen als Claude deze kwetsbaarheid al heeft gevonden en of je de opdracht alleen op specifieke bestanden kunt uitvoeren. Korte antwoorden, zonder omhaal.
**Wat kost één uitvoering?** Dat hangt af van de projectgrootte. Voor mijn project van 30K regels kost één uitvoering ongeveer \$0.30-0.50 aan API-tegoed. Een grote bedrijfsrepository met een miljoen regels kost tot \$5-8 per uitvoering. Dat is tientallen keren goedkoper dan een abonnement op welke SaaS-scanner dan ook. **Hoe vaak moet ik de opdracht lokaal uitvoeren?** Minimaal vóór elke productierelease. Overweeg de controle ook vóór belangrijke commits en PR’s. Dit artikel biedt geen gecontroleerde automatische hook die commits blokkeert. **Met welke stacks werkt deze?** Met alles wat Claude kan lezen. Volgens de waarnemingen van de auteur zijn deze stacks gecontroleerd: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. De kwaliteit is lager bij zeer exotische talen (Erlang, Elixir, Clojure), maar de opdracht vindt wel iets. **Wat moet ik doen als Claude elke keer dezelfde “kwetsbaarheid” vindt, terwijl het eigenlijk geen kwetsbaarheid is?** Voeg deze toe aan `false-positive-filtering-instructions` met een uitleg van “waarom dit veilig is”. Claude zal er bij toekomstige uitvoeringen niet meer over rapporteren. **Kan ik de opdracht alleen op specifieke bestanden uitvoeren?** Lokaal wel: voer simpelweg `/security-review src/lib/auth/*.ts` uit. In de GitHub Action wordt alleen de diff van de huidige PR gecontroleerd, wat meestal wordt bedoeld met “specifieke bestanden”. ## Bronnen
### Bronnen - [Anthropic - Aankondiging van de lancering van Claude Code Security](https://www.anthropic.com/news/claude-code-security) - officiële aankondiging van 20 februari 2026 - [Anthropic Help Center - Geautomatiseerde beveiligingscontroles in Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - officiële instructies voor gebruik - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - bron van de GitHub Action met de volledige README - [Claude Code Docs - Code review](https://code.claude.com/docs/en/code-review) - algemene Anthropic-documentatie - [Anthropic Help Center - Claude Security gebruiken](https://support.claude.com/en/articles/14661296-use-claude-security) - gerelateerde producten - [Port - Claude Code Security Review-resultaten importeren](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - integratie van resultaten in een Internal Developer Portal - [Claude Code Changelog](https://code.claude.com/docs/en/changelog) - geschiedenis van opdrachtreleases
Aanvullend materiaal vind je in de [Ailoot-documentatie](https://ailoot.ai/docs/).
[Ailoot-gidsen](https://ailoot.ai/docs/)
[Naar Ailoot](https://ailoot.ai/)
## Vragen en antwoorden ### Bewijst een schoon security-review-rapport dat de applicatie veilig is? Nee. Het is een eerste codereview met mogelijke gemiste problemen en filtering. Controleer oplossingen, test rol- en gelijktijdigheidsgedrag in staging en bekijk de werkelijk geïmplementeerde configuratie. ### Blokkeert de GitHub Action hier automatisch commits of merges? De getoonde workflow bewijst zo’n garantie niet. Hij plaatst PR-bevindingen. Beoordeel die en test bevestigde oplossingen; het artikel levert geen gecontroleerde lokale hook die commits blokkeert. ## Ailoot · Het bedrijf en zijn projectenportefeuille Ailoot bouwt op opgebouwde operationele ervaring, een groot klantenbestand, een stabiele dienst en doorlopende KPI-controle. Het bedrijf en zijn projectenportefeuille: miljoenen klanten; maandelijkse verkopen in de miljarden. Ailoot gebruikt die operationele ervaring voor API-toegang tot AI-functies in klantproducten, agents, applicaties en automatiseringen.