Wie controleert de agent-harness?

Governance die u zelf kunt controleren, in plaats van governance die u alleen wordt beloofd.

Een agent-harness is de runtime-laag waarin uw agents worden uitgevoerd. Deze bepaalt welke tools ze kunnen aanroepen, waartoe ze toegang hebben en wat wordt vastgelegd. De meeste harnesses zijn cloudgebaseerde control planes. Dat betekent dat de laag die uw governance afdwingt, een laag is die u niet zelf kunt inspecteren. Werkt u in een omgeving waar audits plaatsvinden, dan is dat de eerste vraag die u zou moeten stellen. Toch doet bijna niemand dat.

Een agent-harness is de runtime-laag waarin uw agents worden uitgevoerd.

Niet het model. Niet het framework waarin u de agent hebt geschreven. De laag daaronder die de agent daadwerkelijk uitvoert. Deze bevat de tools die een agent mag aanroepen, het geheugen waartoe de agent toegang heeft, de referenties die de agent mag gebruiken en het overzicht van wat de agent heeft gedaan. Wanneer een agent besluit een database te raadplegen, moet iets die actie toestaan, uitvoeren en vastleggen. Dat is de harness.

Het onderscheid is belangrijk, omdat deze drie begrippen steeds door elkaar worden gehaald:

Een framework is de manier waarop u een agent bouwt, oftewel de code die u schrijft. Het draait waar u het uitvoert.

Een harness is de omgeving waarin de agent wordt uitgevoerd, met machtigingen, tools, geheugen en audittrail. Het is infrastructuur, niet de code waarmee u de agent bouwt.

Een control plane is de plek waar u de harness configureert, meestal via een dashboard en meestal ergens anders.

U kunt een agent in elk framework schrijven en in elke harness uitvoeren. De meeste teams ontdekken pas dat er een harness-laag bestaat wanneer ze moeten verantwoorden wat een agent heeft gedaan. Zit u in een gereguleerde omgeving, dan is dat meestal later dan ideaal.

Het eerlijke antwoord is dat bijna iedereen er eerst per ongeluk zelf een bouwt.

U schrijft een agent. Die heeft een tool nodig, dus u koppelt er een aan. De agent moet iets kunnen onthouden, dus u voegt opslag toe. Iemand vraagt wie de agent heeft uitgevoerd, dus u voegt logging toe. Zes maanden later onderhoudt u een harness die u nooit bewust hebt gekozen en die precies de controles afdwingt waar iemand op het moment zelf aan dacht.

Een bestaande harness kopen betekent dat u die controles onderdeel maakt van het platform, in plaats van ze afhankelijk te maken van uw eigen discipline. Dat is het echte argument ervoor. Niet snelheid.

Hier stopt het gesprek meestal. En hier zou het juist moeten beginnen.

Het gesprek over agent-harnesses wordt momenteel gedomineerd door leveranciers die governance aanbieden. Policy-engines. Guardrails. Goedkeuringsworkflows. Auditdashboards. Het bestaat allemaal en veel ervan is goed.

Maar bijna alles draait in de cloud van iemand anders.

Dat betekent dat de laag die uw governance afdwingt, een laag is die u niet kunt lezen, niet zelf kunt hosten en niet aan een auditor kunt laten zien. U krijgt een dashboard dat aangeeft dat u aan de eisen voldoet. U krijgt niet de mogelijkheid om zelf te controleren of dat rapport klopt.

Een governance-laag die u niet kunt auditen, is een belofte, geen controle.

Voor de meeste bedrijven is die afweging prima. Niemand controleert immers de interne werking van uw CRM. Maar werkt u in defensie, bij de overheid, in de gezondheidszorg of in de financiële sector, dan krijgt u uiteindelijk te maken met iemand wiens taak het is om niet alleen vast te stellen dat u controles hebt, maar ook dat die controles doen wat u zegt dat ze doen. Op dat moment is "het dashboard van onze leverancier staat op groen" geen bewijs. Het is een verwijzing naar de bewering van iemand anders.

Als u deze laag evalueert, maken deze vier vragen het verschil tussen een harness die een security review doorstaat en een harness die alleen een demo goed doorstaat.

1. Wie kan de handhavingslaag zelf auditen?

Niet "heeft het een auditlog?" Iedereen heeft een auditlog. De vraag is: kunt u de code lezen die bepaalt wat een agent mag doen?

Als het antwoord nee is, is uw model voor toegangscontrole een bewering van de leverancier over zijn eigen product. Dat kan acceptabel zijn. Het moet in ieder geval een bewuste keuze zijn, en niet iets wat u pas tijdens een assessment ontdekt.

2. Waar draait het en onder wiens jurisdictie valt het?

Een agent-harness raakt aan alles: uw documenten, uw databases, uw referenties en de gegevens van uw klanten. "Waar draait het?" is daarom niet alleen een infrastructuurvraag, maar ook een juridische vraag.

Vraag specifiek: kan het volledig binnen uw eigen perimeter draaien? Niet "we hebben een regio in uw land". Een regio blijft infrastructuur van de leverancier en valt onder diens jurisdictie. Welk rechtssysteem kan toegang afdwingen tot de omgeving waarin uw agents draaien?

3. Hoeveel ervan is afhankelijk van de control plane van de leverancier?

Dit is de vraag die de meeste shortlists stilletjes in een andere volgorde plaatst.

Vraag waarmee het product verbinding maakt en wanneer: beslissingen qua beleid, licentievalidatie, telemetrie of het model zelf. Stel vervolgens de scherpere vraag: blijft het uw beleid handhaven wanneer het geen verbinding kan maken met de control plane?

Een guardrail die stopt met handhaven zodra het netwerk niet beschikbaar is, is geen guardrail. Het lijkt er alleen op. Dit is het testen waard in plaats van ernaar te vragen, omdat het antwoord vaak is: "dat hebben we nog nooit geprobeerd."

4. Welk bewijsmateriaal levert het op dat een auditor accepteert?

Dashboards zijn voor u. Auditors willen artefacten.

Vraag wat het systeem kan exporteren, in welk formaat en over welke gegevens. De bruikbare vorm is: elke prompt, elke tool-aanroep met de bijbehorende argumenten en elke modelreactie, allemaal gekoppeld aan een benoemde menselijke principal. Dit moet exporteerbaar zijn in een formaat dat u zelf kunt overhandigen en bewaren zolang u dat nodig vindt.

De test is of u voor een specifieke actie van zes maanden geleden antwoord kunt geven op de vraag: "Wie heeft dit veroorzaakt, wat heeft diegene gedaan en wat heeft diegene gezien?", zonder de leverancier te hoeven benaderen.

EpicStaff draait op uw eigen infrastructuur, on-premises of in uw eigen cloudomgeving. De broncode is beschikbaar onder de PolyForm Perimeter 1.0.0-licentie: u kunt de code lezen, uitvoeren en aanpassen voor uw eigen gebruik. Dat de code te inspecteren is, is precies wat de licentie beschermt. Commercieel gebruik voor concurrerende producten is wel beperkt, dus lees de voorwaarden voordat u er een product op bouwt. Ook de code die de toegangscontrole regelt, kunt u zelf bekijken.

Rolgebaseerde toegangscontrole en een audittrail van elke prompt, tool-aanroep en modelreactie zijn beschikbaar in de source-available tier, niet in de betaalde tier. U kunt deze gegevens exporteren als JSON of CSV. Omdat u de software zelf host, bepaalt u zelf hoe lang u de exports bewaart en wanneer u ze verwijdert. Het koppelen van auditgegevens aan een benoemde principal staat op de roadmap voor de Enterprise- en Defence-tiers. Single sign-on en de bredere assurance-bundel zijn onderdeel van Enterprise en Defence en zijn op aanvraag beschikbaar als onderdeel van een contract.

Voor uw eigen audits: export van auditlogs, toegangscontroles en gedocumenteerde procedures voor uw SOC 2-, ISO- of BIO-proces.

Bron: github.com/EpicStaff/EpicStaff