Naar inhoud

Voor security- en platformleiders

Zie en bestuur de AI-agents die al in uw omgeving draaien

Uw omgeving heeft nu al meer AI-agents dan uw IAM-diagram toegeeft. Olivares AI ontdekt ze, brengt in kaart wat elke agent kan lezen en schrijven, en geeft u een deny-closed besturingsoppervlak over die toegang — self-hosted, op uw eigen infrastructuur.

Het probleem: u kunt niet besturen wat u niet kunt zien

De agents zijn er al. Een coding assistant met een database-credential, een interne RAG-service die stilletjes schrijftoegang tot een object store kreeg, een geplande taak die een MCP-server aanroept die niemand registreerde. Ze werden ingericht door teams die snel bewogen, en de security-organisatie erft de blast radius zonder ooit de kaart te hebben gezien. Analisten hebben een naam voor deze vorm — agent sprawl — en de governancekloof eronder is meetbaar.

Van de organisaties die een AI-gerelateerd datalek leden, ontbraken bij ruwweg 97% de juiste AI-toegangscontroles (IBM Cost of a Data Breach 2025, Ponemon). Dat is geen verhaal over volwassenheid van tooling; het is de afwezigheid van een besturingsoppervlak. Tegelijk verwacht Gartner dat meer dan 40% van de agentic-AI-projecten vóór eind 2027 wordt geannuleerd, en voorspelt het dat “guardian agents” tegen 2030 10–15% van de agentic-AI-markt uitmaken (Gartner, pers) — de markt prijst in dat ongereguleerde agents het contact met een echte security review niet overleven.

Het patroon is breder dan security-teams. In een voorlopige, nog niet peer-reviewde studie vertoonde ruwweg 95% van de GenAI-pilots geen meetbare P&L-impact, en extern ingekochte tools slaagden ongeveer twee keer zo vaak als interne builds (MIT “GenAI Divide”, NANDA-project, via Fortune, aug. 2025 — voorlopig). Wat de oorzaak ook is, een omgeving vol agents waarvoor niemand verantwoording kan afleggen is precies de toestand waaronder zowel het lekrisico als het verspilde-pilotrisico zich opstapelen.

Dit sluit naadloos aan op het AI TRiSM-kader — trust, risk and security management voor AI — waarin governance en runtime-inspectie als afzonderlijke lagen liggen. Olivares AI is gebouwd om de laag te zijn die agenttoegang ontdekt, observeert en bestuurt, en is eerlijk over waar dat stopt.

Wat Olivares AI een security-leider biedt

Een getypeerde lees/schrijf-toegangskaart als besturingsoppervlak

De toegangskaart modelleert elke agent als knoop en elke resource die deze kan bereiken — databases, object stores, MCP-servers, API’s, queues — als knoop, waarbij elke edge getypeerd is als R (lezen) of RW (lezen-schrijven). Die R-versus-RW-typering is het punt: least-privilege-drift en de blast radius bij incidenten zijn beide functies van schrijf-toegang, niet van loutere connectiviteit, en een platte “heeft toegang”-lijst verbergt juist dat. Dit is verkenning voor verdedigers — dezelfde kaart die een aanvaller zou willen, gebouwd voor de mensen die de omgeving verdedigen.

Het lezen van de volledige graaf is bewust een geprivilegieerde, tenant-scoped en volledig geaudite actie, want een complete kaart van wat elke agent kan raken is zelf een recon-routekaart. De kaart slaat de relatie op — oorsprong, resource, R/RW, bron, betrouwbaarheid, tijdstempels — en nooit de payloads, SQL-bodies, secrets of PII die over de edge stroomden. Wat niet wordt opgeslagen, kan niet lekken.

Toegestaan versus waargenomen: het verschil dat een bevinding wordt

Elke edge draagt twee onafhankelijke feiten: of de toegang toegestaan is (een grant of policy staat het toe) en of die is waargenomen (telemetrie en native audit tonen dat het gebeurt). Het verschil tussen die twee lagen is het besturingssignaal:

  • Onverwachte toegang — waargenomen maar niet toegestaan. Een agent raakte iets aan dat geen enkele grant dekt. Dit is de security-relevante kop.
  • Ongebruikte grants — toegestaan maar nooit waargenomen. Uw concrete least-privilege-opschoonlijst, niet een vage “review uw IAM”-herinnering.

Het verschil is bewust conservatief. Waar het platform een handelende credential nog niet stevig kan koppelen aan de agent waarvoor de grant is geschreven, wordt de edge gemarkeerd als reconciliation_pending — eerlijke onzekerheid, nooit een verzonnen overtreding. Zie toegestaan versus waargenomen voor het volledige reconciliatiecontract.

Betrouwbaarheid die weigert te bluffen

Een security-tool dat overdrijft wat het weet, is erger dan geen tool. Elke edge draagt twee eerlijke assen. Dekking van de R/RW-classificatie is gelaagd in clean | lossy | opaqueclean waar native audit het ondubbelzinnig maakt (Postgres via pgAudit, object storage via CloudTrail, de warehouses, plus een eBPF-backstop op kernelniveau), tot opaque stores (Redis, SQLite, D1) waar de modus wordt gemarkeerd als unknown in plaats van geraden. Attributie is firm waar een identiteitssignaal per agent de toegang aan één agent toewijst, en approximate waar een gedeeld service-account verbergt welke agent handelde. Een clean/firm-edge en een nauwelijks waargenomen edge worden nooit als even zeker weergegeven — lees het betrouwbaarheidsmodel.

Deny-closed governance, dual control en een kill-switch

Governance is read-first en deny-closed. De autorisatiekern is deny-by-default en tenant-scoped en sluit confused-deputy- en IDOR-klassen constructief af. Elke attribuutgebaseerde policy die u erbovenop bedraadt, kan alleen verder beperken — de compositie is een doorsnede, dus een policy kan een grant nooit verruimen.

Waar het product een actie poortbewaakt, is de lus: een oppervlak presenteert (drift, een bevinding) → een geautoriseerde operator beslist → de beslissing wordt vastgelegd. De goedkeuringsengine handhaaft functiescheiding (een aanvrager mag zijn eigen verzoek niet beslissen) en een dubbele-beslisser-bewaking, gesleuteld op stabiele menselijke identiteit — een systeemtoken heeft geen identiteit en kan niet beslissen. Een critical actie draagt een verplichte twee-personen-ondergrens ontleend aan NIST SP 800-53 AC-3(2), gehandhaafd zowel bij aanmaken als opnieuw afgeleid bij beslissen, zodat zelfs een operator-policy die de tier verlaagt een kritieke actie niet eigenhandig kan maken. Een geaudite break-glass-klep bestaat voor het incident om 03:00 — luid van constructie, hardware-stepped-up, time-boxed en gedwongen in post-review.

De kill-switch is de omgevingsbrede deny-poort. Inschakelen is bewust goedkoop (admin-tier, een reden, geen quorum) want een stop die op consensus wacht is geen stop; elke bestuurde actuatiepoort raadpleegt de stop-rij live en faalt closed bij een leesfout. Heractiveren is nooit unilateraal — het is afhankelijk van een verse dual-control-goedkeuring en heeft geen break-glass-pad, want “de omgeving blijft gestopt” is de veilige toestand.

Manipulatiebestendig bewijs

Elke muterende actie wordt toegevoegd aan een append-only, hash-geketend auditlogboek in dezelfde transactie als de wijziging, met de werkelijke actor; gevoelige reads auditen zichzelf in een gecommitte write. Het herschrijven van de historie is detecteerbaar, en het logboek bevat nooit PII. De compliancemodule koppelt dat runtime-bewijs aan controleframeworks, zodat een beoordeling wordt gevoed vanuit waargenomen werkelijkheid in plaats van een vragenlijst.

Wat dit is — en wat het niet is

  • Self-hosted en soeverein. De control plane draait op uw eigen infrastructuur en kan air-gapped worden. Olivares AI is een open, self-hostbaar platform (AGPL-3.0). Zie het security-model en de architectuur.
  • Standaard detectief; deny-closed waar het handelt. Het observeert en bestuurt breed; het actueert niet breed. Waar het een actie kan ondernemen, is dat oppervlak live, on-demand of een verklaarde naad — en de modulecatalogus markeert welke. Een afwezigheid van handhaving is meestal bij ontwerp.
  • Pre-1.0, met een gepubliceerde catalogus van 23 modules (ruwweg 20 vandaag bedraad). Niet alles is live; we zeggen wat wel en niet, in plaats van volledige dekking te impliceren.
  • Air-gap geldt voor de Olivares control plane, niet voor uw modellen. Een gehost model zoals Claude is nooit air-gapped; alleen self-hosted modellen (vLLM, Ollama) draaien offline. Olivares bestuurt de toegang in beide gevallen.
  • Niet gecertificeerd. Olivares AI is ontworpen richting SOC 2, ISO/IEC 42001 en de EU AI Act; het bezit geen certificering en wij claimen er geen.

Hoger-onderwijs- en onderzoeksomgevingen hebben een parallelle versie van dit probleem — breed AI-gebruik onder docenten en staf terwijl formele AI-governance en acceptable-use-dekking achterblijven (EDUCAUSE-onderzoek, 2025). Als dat uw context is, zie hoger onderwijs; platformteams die de infrastructuur draaien, beginnen het best bij platform engineering.

Waar nu naartoe

  • Toegangskaart — de getypeerde R/RW-graaf en de toegestaan-versus-waargenomen-overlay op een echte capture.
  • Kill-switch — de omgevingsbrede deny-poort in producttermen.
  • Compliance — manipulatiebestendig bewijs gekoppeld aan controleframeworks.
  • Governance-concepten — read-first, deny-closed, dual control.
  • Vergelijk — hoe Olivares naast gateways, observability en control towers staat.
  • Aan de slag — zie de kaart op een demo-omgeving.

Vragen

Zit Olivares AI in het verzoekpad tussen een agent en zijn data?

Nee. De control plane is standaard detectief — die neemt logs, OpenTelemetry en native audit out of band in en bouwt de toegangskaart op zonder verkeer te onderscheppen. Een uitgevallen collector kan productie niet platleggen. Waar het product op een bevinding kan handelen, doet het dat deny-closed en op aanvraag, nooit als generieke executor.

Kan de control plane air-gapped draaien?

De Olivares control plane — governance, observatie, het auditlogboek — kan volledig self-hosted en air-gapped op uw eigen infrastructuur draaien. Dat staat los van de modellen die u bestuurt; een gehost model zoals Claude is nooit air-gapped, en alleen self-hosted modellen (vLLM, Ollama) draaien offline. Olivares bestuurt de toegang in beide gevallen.

Is Olivares AI SOC 2- of EU AI Act-gecertificeerd?

Nee. De compliancemodule is ontworpen richting die frameworks en levert manipulatiebestendig bewijs dat gekoppeld is aan hun controls, maar Olivares AI bezit geen certificering en wij claimen er ook geen. Behandel het bewijs als input voor uw eigen beoordeling, niet als een attestatie.

We hebben al een LLM-gateway en een observability-stack. Waarom dit erbij?

Die vertellen u wat is aangeroepen en wat het kostte. Ze geven u geen getypeerde lees/schrijf-toegangskaart over uw datalandschap, geen vergelijking van toegestaan versus waargenomen, en geen deny-closed goedkeuringspoort met een dual-control-ondergrens en een omgevingsbrede kill-switch. Olivares integreert ernaast in plaats van ze te vervangen — zie /compare.

Probeer het op uw eigen infrastructuur

Olivares AI is open-core (AGPL-3.0) en self-hosted. Rol het uit en zie wat uw agents kunnen bereiken.