
Wat is Proof-Derived Authorization?
Proof-derived authorization is een beveiligingsmodel voor AI-agents waarbij elke actie die de agent uitvoert cryptografisch moet worden gerechtvaardigd door een verifieerbaar bewijs van de autorisatieketen — van de oorspronkelijke menselijke principaal tot en met eventuele tussenliggende orchestrators — waardoor ongeautoriseerde acties wiskundig onmogelijk worden in plaats van slechts beleidsmatig verboden.
Waarom het ertoe doet
Naarmate AI-agents toegang krijgen tot gevoelige systemen, wordt de vraag wie heeft deze actie geautoriseerd kritiek. Huidige agent-frameworks vertrouwen op prompt-gebaseerde toegangscontrole: de system prompt instrueert de agent bepaalde acties niet uit te voeren. Proof-derived authorization vervangt dat door cryptografische garanties:
- Elimineert prompt injection als aanvalsvlak: Een adversariale prompt kan een agent niet instrueren een actie te ondernemen waarvoor geen geldig bewijs kan worden geconstrueerd. De bewijs-eis wordt afgedwongen buiten het contextvenster van het LLM.
- Maakt soevereine AI-infrastructuur mogelijk: Enterprises en overheden kunnen AI-agents inzetten met dezelfde auditeerbaarheid als menselijk-bediende systemen — elke actie heeft een ondertekend, tijdgestempeld autorisatierecord.
- Voorkomt agent-imitatie: In multi-agent pipelines kan een gecompromitteerde sub-agent de autorisatie van een hoger-niveau orchestrator niet vervalsen zonder toegang tot de corresponderende cryptografische sleutels.
Hoe het werkt
Het framework beschreven in Verifiable Agentic Infrastructure werkt in drie lagen:
- Root-autorisatie — Een menselijke principaal ondertekent een autorisatietoken dat een scope specificeert (bijv. "lees en wijzig bestanden in /project/src, geen toegang tot /etc") met zijn privésleutel.
- Delegatieketen — Elke orchestratorlaag ondertekent het token opnieuw, waarbij de scope mogelijk wordt versmald (maar nooit uitgebreid), voordat het wordt doorgegeven aan de volgende agent.
- Actie-tijd bewijsverificatie — Vóór het uitvoeren van een tool-aanroep verifieert de runtime van de agent of er een geldige bewijsketen bestaat voor dat specifieke actietype. Als verificatie mislukt, wordt de actie geweigerd ongeacht wat de output van het LLM zegt.
Voorbeeld
Een financieel bedrijf zet een autonome reconciliatie-agent in. De CFO ondertekent een root-token dat "read-only toegang tot alle accounts, schrijftoegang tot het reconciliatieledger" verleent. Het token wordt gedelegeerd aan de orchestrator, die het versmalt naar een specifiek datumbereik en delegeert naar de reconciliatie-sub-agent. Wanneer de sub-agent een correctieve boeking probeert te schrijven, verifieert de runtime de bewijsketen in milliseconden. Als een adversariale prompt de sub-agent misleidt om een fondsenoverboek te proberen, mislukt de poging onmiddellijk — niet omdat een beleid het verbiedt, maar omdat er geen geldig bewijs voor "fondsen overboeken" kan worden geconstrueerd.