Self-hosted AI agents: vijf securitygates vóór browser- en tooltoegang

Een self-hosted AI agent kan een aantrekkelijk alternatief zijn wanneer je meer zeggenschap over infrastructuur, data en integraties wilt. Maar “draait op onze eigen server” is geen securitycontrol. Als dezelfde agent een browser, files, netwerk en tools kan gebruiken, moet elke grens expliciet zijn.

Deze tutorial gebruikt een vendorneutrale fictieve declaratie-agent. OpenBot is de actuele bron voor enkele concrete ontwerpkeuzes: het project noemt zichzelf op 17 september 2026 een alpha-template, geen hosted product. Release v0.0.10 verscheen op 13 september. Gebruik zo'n project als ontwerpinput, niet als een stempel dat jouw deployment klaar is voor productie.

Welke vijf gates heb je nodig?

De gates zijn onafhankelijk. Als één gate open staat, vult self-hosting dat niet op.

Deze gates horen vóór modelkeuze, promptkwaliteit en zelfhostingkosten. Het model beslist over een voorstel; de gates beslissen of een effect mag gebeuren.

Gate 1: maak gebruikersidentiteit een harde voorwaarde

Een lokale developmentmodus kan een single-user default hebben. Dat is praktisch op een laptop, maar geen multi-user autorisatiemodel. De OpenBot-README waarschuwt dat de lokale setup een single-administratormodus gebruikt totdat sign-in is ingericht.

Voor een fictieve declaratie-agent is het minimum:

pattern: voorbeeld
identity:
  required: true
  subject: "geauthenticeerde gebruiker"
  roles:
    submitter: [read_status, create_draft]
    approver: [approve_export]
session:
  tenant_scope: "server-side afgedwongen"

De tenant- en rolcheck hoort server-side bij de toolgateway, niet alleen in de system prompt. Een prompt kan de identiteit uitleggen, maar kan hem niet bewijzen.

Gate 2: houd secrets buiten agentconfiguratie

Zet credentials niet in agent-YAML, prompts of een browserprofiel. Gebruik een secretstore of ten minste omgevingseigenschappen die niet worden gelogd en alleen aan de juiste runtime worden doorgegeven. Maak onderscheid tussen:

• de modelcredential;
• een toolcredential per externe dienst;
• een token waarmee een agentcomputer de gateway aanspreekt;
• een gebruikerssessie of delegated token.

Geef elk token een kleine scope, korte levensduur waar dat kan en een rotatiepad. Een logregel mag een request-ID en credentialtype noemen, nooit de waarde. Deze discipline sluit aan op de securitykant van AI-agenten in productie.

Gate 3: isoleer browser, filesystem en netwerk

Een agentbrowser bevat echte logins en een agent-shell kan alles bereiken wat het container- of hostnetwerk toestaat. Behandel hem dus als een aparte execution zone.

De OpenBot-architectuur beschrijft onder meer een eigen computer per bot, loopback endpoints en een gescheiden datanetwerk. Neem daaruit het patroon over, niet blind de defaults:

1. geef elke agent een eigen browserprofiel en workspace;
2. laat agentcomputers niet standaard bij databases of interne adminpoorten;
3. zet private-hosttoegang standaard uit;
4. beperk egress tot benodigde domeinen of een gecontroleerde proxy;
5. test DNS, HTTP en filesystem-denials expliciet.

Isolatie is geen reden om autorisatie te skippen. Een verkeerde toolscope binnen een perfecte container blijft een verkeerde toolscope.

Gate 4: begin met deny en voeg per tool een policy toe

Een policy hoort actie, doel en context te beoordelen. “De agent mag exporteren” is te breed; beter is “de rol approver mag deze export, voor dit dossier, na een goedgekeurde review.”

{
  "tool": "export_declaration",
  "allow_when": [
    "actor.role == 'approver'",
    "request.approval_id is valid",
    "target.domain == 'belastingdienst.example'"
  ],
  "otherwise": "deny_and_audit"
}

De OpenBot-documentatie beschrijft deny-before-allow en fail-closed als patroon. Controleer altijd de actuele configuratie: een shipped development default kan bewust ruimer zijn dan je productietoepassing. Bij meer dan één tool of MCP-server helpt een MCP-server zonder sessies om grenzen rond stateless requests, identiteit en toolinterfaces expliciet te maken.

Gate 5: schrijf een audittrail die failures niet mooier maakt

Een auditregel moet vertellen wie een actie vroeg, welke policy besliste, wat het resultaat was en of de uitvoerder weigerde of faalde. “Geen resultaat gevonden” is niet hetzelfde als “de gateway gaf 403 terug.”

Leg bijvoorbeeld vast:

run_id, actor_id, tool, target_class, policy_version,
decision=denied, reason=missing_approval, execution=not_started

De recente OpenBot-release v0.0.10 laat zien waarom dit detail telt: die corrigeert situaties waarin een bot een geweigerde toolcall als “niets gevonden” kon doorgeven. In je eigen systeem moet een deny als deny te herkennen zijn in UI, log en alert.

Hoe test je de gates vóór browser- en tooltoegang?

Maak een testmatrix met zowel toegestane als geweigerde gevallen. Claim geen geslaagde test zolang je hem niet echt hebt gedraaid.

Voeg een observabilitycheck toe: tel denials, verlopen tokens en policyversies, maar redigeer invoer en toolargumenten waar zij persoonsgegevens of secrets kunnen bevatten.

Wanneer kies je niet voor self-hosting?

Kies een beheerde AI-API wanneer het team geen 24/7 verantwoordelijkheid voor runtime, patching, identity en observability kan dragen. Kies een klassieke webapp voor een vaste, voorspelbare workflow zonder agentische vrijheid. Kies self-hosting alleen wanneer de extra controle past bij de operatie die je ook echt kunt beheren.

Voor een ontwerp waarin open modellen, self-hosting en beheerde API's naast elkaar worden afgewogen, kan een AI engineer inhuren helpen om de gates, kosten en verantwoordelijkheden vóór de build vast te leggen.