Proof-derived authorization beperkt wat een AI-agent in je systemen kan doen. De agent krijgt geen vaste beheerdersrechten. Voor iets riskants, zoals een server verwijderen, dient hij een verzoek in: het systeem legt vast waarom de actie zou mogen, onafhankelijke controles keuren die goed of af, en de agent krijgt een tijdelijke sleutel voor alleen die ene actie. Achteraf kun je nagaan waarom het mocht.
Waar komt de term vandaan?
Jun He en Deying Yu van het bedrijf OpenKedge introduceerden de term in mei 2026 in Verifiable Agentic Infrastructure: Proof-Derived Authorization for Sovereign AI Systems. Hun vertrekpunt is dat cloudsystemen toegang geven op basis van identiteit: wie geldige inloggegevens heeft, mag elk commando uitvoeren dat die gegevens toestaan. Een AI-agent kan commando's maken die technisch geldig maar onveilig zijn, en dan worden vaste rechten een risico. Volgens de auteurs weegt dat risico het zwaarst in "soevereine" AI-systemen, waarin agents werken met cloudinfrastructuur, gereguleerde gegevens, financiële processen of nationale digitale diensten. Het artikel bouwt voort op OpenKedge (april 2026), een protocol van dezelfde auteurs waarin agents een voornemen indienen in plaats van systemen direct te wijzigen.
Hoe werkt het?
Het Distributed Trust Framework (DTF) uit het artikel doorloopt vier stappen in een vaste volgorde:
- Justification Proof: een gestructureerd verslag van de voorgestelde actie, de context op het moment van beslissen, het beleid dat geldt, een risico-inschatting en de ruimste bevoegdheid die mag worden verleend (actie, bron, tijdvak en voorwaarden). Met proof (bewijs) bedoelen de auteurs dit verslag: expliciet en machineleesbaar, zodat beoordelaars en auditors het later opnieuw kunnen controleren.
- Consensus: meerdere onafhankelijke beoordelaars, zoals een beleidscontrole, een controle op afhankelijkheden, een simulatie of een menselijke reviewer, beoordelen hetzelfde verslag. Riskantere acties vragen een groter quorum of een menselijke beoordeling, en sommige beoordelaars hebben een veto.
- Execution Identity: na goedkeuring krijgt de agent kortlevende inloggegevens die alleen gelden voor de goedgekeurde actie, bron en tijdvak, op AWS bijvoorbeeld een tijdelijke STS-sessie met een smal beleid.
- Evidence Chain: een logboek waaraan alleen kan worden toegevoegd, met het verslag, de beoordelingen, het besluit, de inloggegevens en de uitkomst, zodat een auditor later kan naspelen waarom de actie mocht. Knoeien moet zichtbaar zijn, bijvoorbeeld via hashkoppelingen of handtekeningen; het artikel schrijft geen specifieke cryptografische methode voor.
Wat hebben de auteurs gemeten?
Hun prototype, ongeveer 4.500 regels Go op AWS, verwerkte 10.000 synthetische agentacties in een gesimuleerde cloud, waarvan 2.400 onveilig. DTF blokkeerde of escaleerde alle 2.400; een beleidscontrole alleen liet er 336 door. Vaste inloggegevens gaven per rol gemiddeld toegang tot 450 bronnen, terwijl elke DTF-goedkeuring er 1 besloeg. Auditors konden het besluit reconstrueren voor 9.991 van de 10.000 acties, tegen 2.300 met gewone auditlogs. Een besluit kostte gemiddeld 58,3 milliseconden. De auteurs benadrukken dat dit een gecontroleerde werklast was, die niets bewijst over correctheid in de open wereld.
Waar liggen de grenzen?
- Het artikel stelt dat DTF prompt injection in de agent zelf niet oplost. Het beperkt wat een misleide agent goedgekeurd en uitgevoerd kan krijgen.
- Een bewijs is zo goed als de invoer. Met verouderde context of verkeerd beleid legt het de verkeerde reden keurig vast.
- Beoordelaars die dezelfde gegevens of blinde vlekken delen, beschermen minder dan hun aantal doet vermoeden.
- Het gaat ervan uit dat elke riskante actie echt door het framework loopt en dat de controlelaag zelf niet is gecompromitteerd.
- Het kost vertraging, opslag en beheerwerk, wat de auteurs alleen de moeite waard vinden voor acties met grote gevolgen.
Voorbeeld
Het voorbeeld uit het artikel zelf is een agent die voorstelt een cloudserver te verwijderen (terminate). Het verslag noemt het doel, de netwerktopologie, het huidige verkeer, de eigenaar, beschermingslabels en een eventueel lopend incident, plus het beleid voor destructieve acties. Ligt de server op een afhankelijkheidspad, dan markeert de risico-inschatting de actie als kritiek. Het resultaat is ofwel helemaal geen toestemming, ofwel inloggegevens voor precies die server, die actie en dat tijdvak, eventueel met de voorwaarde om het verkeer vlak voor het verwijderen opnieuw te controleren. Volgens de auteurs vervangt het verslag zo een vage bewering als "the instance appears unused".