Nango: de integratielaag die je AI agent wél mag vertrouwen met API's

Een paar weken geleden zat ik met een klant om tafel, een middelgrote gemeente die AI wilde inzetten voor automatische verwerking van burgeraanvragen. Het plan: een agent die inlogt op het zaaksysteem, relevante dossiers ophaalt, een conceptbesluit schrijft, en dat ter goedkeuring voorlegt. Technisch goed te doen. Maar toen kwam de vraag waar het meestal misgaat: "En hoe regelen we dat die agent veilig bij het zaaksysteem kan?"

Het eerlijke antwoord: dat is het moeilijkste deel van het hele project.

Niet het model. Niet de prompt. Niet de RAG-pipeline. Maar de integratielaag, OAuth tokens, token-refresh, per-user rechten, rate-limits, logging, en vooral: zorgen dat die credentials nooit in handen van het model zelf komen.

Dat is precies het probleem dat Nango oplost. En dat maakt het strategisch relevant, niet als "weer een integratieplatform", maar als credential-aware integration runtime voor agentic workflows.

Wat is Nango? De drie primitieven

Nango is een open-source platform dat 800+ API's beheert en als integratielaag fungeert tussen jouw applicatie, of je AI agent, en externe SaaS-systemen. De repo heeft zo'n 9.500 stars, bijna duizend forks, en wordt actief gebruikt door bedrijven als Replit, Ramp en Mercor.

De kern bestaat uit drie primitieven:

Auth. Managed OAuth, API keys en token-refresh voor 800+ API's. Nango slaat credentials encrypted op, handelt token-rotatie af, en biedt een white-label auth-flow die je in je eigen applicatie embedt.

Proxy. Maak authenticated API-requests namens gebruikers zonder dat de caller ooit de ruwe token ziet. Je stuurt een connectionId mee, Nango resolved de provider, injecteert de credentials, handelt retries en rate-limits af, en retourneert het resultaat.

Functions. Schrijf integratielogica als TypeScript-functies die draaien op Nango's productie-runtime. De AI builder kan ze genereren uit een beschrijving van je use case. Dit is waar Nango relevant wordt voor AI agents: je agent roept een function aan, Nango voert uit, en de credentials blijven veilig op de achtergrond.

De architectuur onder de motorkap is volwassen: Server, Orchestrator, Jobs, Runner, Persist, Postgres, Object Storage, ElasticSearch en Redis, elk met een duidelijke rol en elk met eigen risicozones die je in gereguleerde context moet begrijpen.

Waarom dit wél het echte probleem oplost

Bij de meeste AI-agent-projecten zie ik hetzelfde patroon: de discussie gaat over welk model het beste is, welke vector-database het snelst is, of je LangChain of LlamaIndex moet gebruiken. Maar niemand heeft het over de integratielaag. En juist daar ontstaat het grootste risico.

Een agent die zelf OAuth tokens beheert, zelf API-calls construeert, en zelf data schrijft naar externe systemen, dat is een security-nachtmerrie. Het blast-radius van één gecompromitteerde prompt is dan niet beperkt tot een fout antwoord, maar strekt zich uit tot elke SaaS-applicatie waar die agent toegang toe heeft.

Nango's architectuurprincipe is fundamenteel juist:

Agent / LLM
  ↓ tool call
Application policy layer
  ↓ selected action + connectionId
Nango
  ↓ credential injection + execution + logs
External SaaS / API

De agent ziet alleen de tool-naam en een connectionId. De credentials blijven in Nango's kluis. De applicatie bepaalt welke tool voor welke gebruiker beschikbaar is. Dit is niet alleen veiliger, het is de enige architectuur die schaalbaar te auditen is.

De keerzijde: Nango wordt de kroonjuwelenkluis

Maar hier zit precies het grootste risico: doordat Nango alle credentials beheert, wordt het zelf een high-value credential broker. Als Nango gecompromitteerd raakt, is niet één systeem lek, het zijn álle gekoppelde systemen tegelijk.

De security-aandachtspunten zijn reëel:

Encryptie is opt-in, niet verplicht. Self-hosting vereist een NANGO_ENCRYPTION_KEY om credentials te versleutelen. Zonder deze environment variable worden tokens plaintext opgeslagen. Dat is geen theoretisch risico, het is een misconfiguratie die ik in de praktijk vaker zie dan me lief is.

Key rotation ontbreekt. De documentatie is er glashelder over: wijziging van de encryptiesleutel na initiële setup veroorzaakt decryptiefouten. Voor strikte KMS/HSM-compliance is dat onvoldoende, je moet aanvullende procedures inregelen voor key compromise scenario's.

MCP-endpoint is een aantrekkelijk doelwit. Nango exposeert alle enabled action functions via één MCP-endpoint. De secret key in de MCP client-config wordt daarmee een high-value asset. Lekkage daarvan geeft toegang tot alle tools van alle verbonden tenants.

Connection ownership ligt buiten Nango. Je moet zelf bijhouden welke connectionId bij welke gebruiker of tenant hoort. Als die mapping zwak is, ontstaan confused-deputy scenario's waarbij agent A per ongeluk handelt namens organisatie B.

Runner executeert integratiecode. In self-hosted setups draait de Runner integratielogica uit. Supply-chain attacks op integratiecode, of sandbox-escapes, zijn reële dreigingen die je zelf moet mitigeren.

Voor gereguleerde omgevingen, en daar vallen overheidsklanten per definitie onder, zijn dit geen kanttekeningen maar harde ontwerpeisen.

De minimale security baseline voor BIO2/NIS2-context

Als ik Nango zou inzetten voor een Nederlandse overheidsklant, dan gelden deze minimale controls:

• Verplichte encryption-at-rest via externe secret manager (Vault, Azure Key Vault, AWS KMS)
• Separate keys per omgeving, dev, test, acceptatie en productie krijgen elk hun eigen encryptiesleutel
• Eigen OAuth apps per provider, nooit shared developer apps van Nango gebruiken voor productie
• Policy gateway vóór MCP-exposure, tools pas aanbieden aan de agent na ABAC-check op tenant, gebruiker, actie, scope en dataclassificatie
• Tool allowlisting per workflow, een agent die facturen verwerkt krijgt geen toegang tot de mail-API
• Human-in-the-loop voor schrijfacties, writes, deletes, sends en payment-acties vereisen altijd goedkeuring
• OTel-export naar SIEM met correlation IDs, policy decision IDs en immutable audit trail
• Runner-isolatie per tenant waar mogelijk, met netwerksegmentatie en egress-allowlisting

Zonder deze laag is Nango een krachtig stuk gereedschap in het handschoenenkastje van een onervaren bestuurder. Mét deze laag wordt het de integratie-runtime waarop je veilig agentic workflows kunt bouwen.

Waar Nango scoort, en waar niet

In architectuurkwaliteit en agentic AI-fit scoort Nango hoog. De service-decompositie is logisch, de credential-separatie is architectonisch zuiver, en de expliciete documentatie over wat wél en niet in de agent-runtime thuishoort getuigt van security-volwassenheid.

Maar de enterprise-readiness kent scherpe kantjes. De Elastic License 2.0 verbiedt managed services, je kunt Nango niet als SaaS aanbieden zonder commerciële licentie. De gratis self-hosted versie is beperkt: geen Functions, geen Webhooks, geen MCP-server, geen OpenTelemetry, geen RBAC, geen SAML SSO. Voor productie in een gereguleerde context is het Enterprise plan de enige reële route.

Het licentiemodel creëert een lock-in risico: bij strategische afhankelijkheid van Nango moet je een exit-plan hebben voor tokens, integraties en action code, voor het geval licentievoorwaarden veranderen of het bedrijf wordt overgenomen.

Wat DjimIT hiermee doet

Nango is voor ons geen product om te verkopen. Het is een bouwsteen in een groter verhaal: Secure Agentic AI Execution voor organisaties die wél de vruchten van AI willen plukken, maar niet het risico willen lopen op uncontrolled API-toegang.

Drie proposities die hieruit volgen:

• Secure MCP Gateway, agents veilig laten handelen in SaaS-systemen met policy, audit en approval, met Nango als uitvoeringslaag onder een eigen governance-framework
• OAuth Governance Accelerator, OAuth app-registratie, scope-minimalisatie, token-lifecycle en tenant-mapping volgens BIO2-eisen
• AI Governance Evidence Trail, OTel, SIEM, policy decisions en approval logs als auditeerbaar bewijs voor AI Act Article 14 (human oversight) en BIO2-audits

De sterkste invalshoek voor ons merk: Nango levert de integratie-uitvoering, "van data naar doen." DjimIT levert de governance, policy, security en het enterprise operating model eromheen.

Conclusie

Nango is geen wondermiddel. Het is een volwassen, goed ontworpen bouwsteen voor een heel specifiek probleem: hoe zorg je dat AI agents kunnen handelen in de echte wereld van SaaS-systemen, zonder dat je de sleutels van het koninkrijk aan een taal-model geeft?

Het antwoord is niet "gebruik Nango en je bent veilig." Het antwoord is: gebruik Nango als credential-aware execution substrate, bouw je eigen policy-control-plane eromheen, en behandel Nango zelf als de meest kritieke schakel in je architectuur.

Want dát is het geworden zodra je het in productie neemt.

---

Dit artikel kwam tot stand op basis van een security-architectuuranalyse van NangoHQ/nango v0.70.5. De technische evaluatie en security-aanbevelingen zijn gebaseerd op de documentatie, source code, en architectuur zoals beschikbaar in mei 2026.