Technisch overzicht: Sovereign Assurance Boundary voor Agentic Infrastructuur

1. Probleemstelling

De integratie van Large Language Model (LLM) agents in operationele workflows introduceert een kritieke autorisatiekloof in de control-plane. Hoewel agents hoogwaardige mutaties aan productieresources kunnen voorstellen (bijv. het schalen van nodes, het roteren van credentials, het wijzigen van netwerkbeveiligingsgroepen), zijn bestaande beveiligingsmechanismen onvoldoende om deze niet-deterministische redeneersystemen te beheersen.

• Statisch vs. Dynamisch: Traditionele Identity and Access Management (IAM) en policy engines handhaven statische permissies of structurele compliance, maar kunnen niet bepalen of een autonoom voorstel semantisch gerechtvaardigd is door actuele bewijslast.
• Post-Hoc Beperkingen: Auditlogs en consensusprotocollen registreren acties of komen overeen over staatsovergangen pas na uitvoering, of zonder de semantische veiligheid van de transitie te evalueren.
• Risicoaccumulatie: Individueel plausibele acties van agents kunnen cumulatief leiden tot systemische fouten, inclusief beschikbaarheidsuitval, datalekkage, beleidsomzeiling en verlies van forensische context.
• De Kernkloof: Er is geen runtime-toelatingsgrens die een voorstel van een agent omzet in uitvoeringsautoriteit, behalve nadat het is gebonden aan bewijs, beleid en revocatie-status.

2. Methodologie: De Sovereign Assurance Boundary (SAB)

Het paper stelt de Sovereign Assurance Boundary (SAB) voor, een certificaat-gebonden runtime-toelatingsgrens die tussen de redenering van de agent en de infrastructuur-mutatie staat. SAB opereert op het principe dat de instelling lokale controle behoudt over beleid, bewijs en uitvoeringsautoriteit, waarbij de agent-runtime wordt behandeld als een onbetrouwbare voorsteller.

2.1 Architectuur: Airlock–Broker Model

SAB scheidt het systeem in twee afzonderlijke lagen:

1. Onbetrouwbare Agent Runtime: Genereert voorstellen maar bezit geen staande credentials of directe uitvoeringsrechten.
2. Vertrouwde Sovereign Execution Broker: De enige entiteit die bevoegd is om infrastructuur-API's aan te roepen. Deze voert mutaties uitsluitend uit na verificatie van een ondertekend Sovereign Assurance Certificate ($\Omega$).

De toelatingspipeline bestaat uit de volgende fasen:

• Contract Compilatie: Ruwe agent-commando's worden genormaliseerd naar een sterk getypeerd Execution Contract ($C$), dat targets, precondities, postcondities en rollbacks definieert.
• Evidence Binding: Een evidence collector assembleert telemetrie, logs en tickets om een cryptografische digest $H(E)$ van de systeemtoestand op het moment van besluitvorming te berekenen.
• Consequence Scoring: Een scorer berekent een risicometriek $R(C)$ op basis van de impact (blast radius), privilege expansie, gegevensgevoeligheid, onomkeerbaarheid en onzekerheid. Dit bepaalt het Autonomie Niveau ($L(C)$) (variërend van L0 Advisory tot L5 Prohibited).
• Certificeringstraject Routing: Op basis van $L(C)$ en beleid wordt het contract door een specifiek traject gerouteerd (bijv. PolicyOnly, LightweightQuorum, SQA, SQAPlusHuman).
  • Semantic Quorum Assurance (SQA): Een mesh van externe, onbetrouwbare validators levert ondertekende attestaties ($\Gamma_{SQA}$) met betrekking tot de semantische toelaatbaarheid van de actie.
  • Menselijke Goedkeuring: Voor acties met hoge impact leveren operators multi-signature goedkeuringen die gebonden zijn aan het specifieke contract en het bewijs.
• Certificaat Issuance: De Assurance Airlock (onderdeel van de Trusted Computing Base) verifieert alle vereisten van het traject en geeft een ondertekend Sovereign Assurance Certificate ($\Omega$) uit.
  • $\Omega$ bevat: $C$, $H(E)$, $R(C)$, $L(C)$, certificeringstraject, validator-handtekeningen, uitvoeringsidentiteit ($ID_{exec}$), geldigheidsvenster ($T_{valid}$), beleidsversie ($P_{ver}$) en revocatie-epoch ($\rho_{rev}$).
• Broker Verificatie: Voordat uitvoering plaatsvindt, verifieert de Sovereign Broker de handtekening van $\Omega$, controleert de revocatie-epoch, valideert de beleidsversie en voert een state drift check ($\Phi_{drift}$) uit om te garanderen dat de live status niet is afgeweken van het gebonden bewijs $E$.

2.2 Formele Invarianten

SAB handhaaft vijf autoriteitsgrens-invarianten:

1. Voorstel-Uitvoering Ontkoppeling: Geen enkel agent-voorstel triggert een mutatie zonder toelating door de airlock.
2. Certificaat-Gebonden Uitvoering: Uitvoering vindt alleen plaats als de broker een geldig $\Omega$ verifieert dat het specifieke contract $C$ bevat.
3. Evidence Binding: Goedkeuringen en attestaties zijn cryptografisch gebonden aan $C$ en $H(E)$, wat hergebruik in andere contexten voorkomt.
4. Monotone Padselectie: Contracten worden alleen toegelaten als aan alle vereisten van hun gekozen certificeringstraject wordt voldaan; paden met lagere assurance kunnen niet de eisen van hogere risico's overrulen.
5. Ephemere Autoriteit: Certificaten worden afgewezen als de revocatie-epoch verouderd is of als de uitvoering buiten het geldigheidsvenster valt.

3. Belangrijkste Bijdragen

Het paper levert vier primaire bijdragen:

1. Certificaat-Gebonden Toelating: Het definieert een runtime-toelatingsgrens die autonome uitvoeringsautoriteit omzet van een ambient permissie naar een herroepbaar, aan bewijs gebonden artefact.
2. Airlock–Broker Architectuur: Het introduceert de specifieke componenten (Contract $C$, Evidence Digest $H(E)$, Certificate $\Omega$, en Sovereign Broker) die voorstel, toelating en uitvoering scheiden.
3. Consequence-Aware Certificering: Het formaliseert consequence scoring, autonomieniveaus, certificeringstrajecten en revocatiemechanismen die escalatie, afwijzing en opschorting ondersteunen vóór uitvoering.
4. Prototype en Haalbaarheids Evaluatie: Het implementeert een Go-prototype dat de haalbaarheid van het systeem demonstreert, inclusief contract-serialisatie, OPA/Rego policy checks, Ed25519 signing en een PostgreSQL-gestuurde ledger.

4. Resultaten en Evaluatie

De auteurs hebben het prototype geëvalueerd met 500 gelabelde uitvoeringcontracten over 2.500 toelatingspogingen in een lokale testomgeving.

• Latentie:
  • Policy-only toelating: ~1,84 ms (p50).
  • SQA toelating (met validator mesh): ~185 ms (p50) / 380 ms (p95).
  • Broker verificatie: ~0,15 ms (p50).
  • Revocatie propagatie: ~12,4 ms (p95).
• Nauwkeurigheid:
  • Routing nauwkeurigheid (overeenstemming met expert-gelabelde oracle): 96,8%.
  • Onveilige toelatingsratio: 0,4%.
• Efficiëntie:
  • Reductie in menselijke goedkeuring: 68,2% vergeleken met een mens-alleen wachtrij.
  • Certificaat opslagoverhead: ~3,4 KB per actie.
• Replaybaarheid: 100% van de ledger-entries waren replaybaar met schema-context.

De resultaten geven aan dat de control-plane overhead haalbaar is op een enkele workstation, waarbij latentie wordt geruild voor assurance en replaybaarheid.

5. Betekenis en Claims

Het paper claimt dat SAB een specifieke autorisatiekloof aanpakt zonder bestaande beveiligingslagen te vervangen.

• Operationele Soevereiniteit: SAB definieert soevereiniteit als het behoud van lokale controle door de instelling over beleidsevaluatie, bewijsretentie, signer-keys en uitvoeringsautoriteit. Externe modellen zijn beperkt tot het genereren van voorstellen en kunnen de lokale certificering niet omzeilen.
• Composability: SAB is geen vervanging voor IAM, formele verificatie, consensusprotocollen of menselijke review. In plaats daarvan componeert SAB deze mechanismen tot een systeem-niveau toelatingsgrens. Het behandelt gedelegeerde uitvoeringsautoriteit als een certificaat-gebonden, aan bewijs gebonden, herroepbaar en replaybaar runtime-artefact.
• Risicomitigatie: Door het genereren van voorstellen te ontkoppelen van de uitvoering en uitvoering te binden aan actueel bewijs en actief beleid, voorkomt SAB dat autonoom redeneren alleen al de staat kan muteren, waardoor risico's van systemische fouten, datalekken en beleidsomzeiling worden gemitigeerd.

De auteurs hanteren een bescheiden standpunt en erkennen dat SAB afhankelijk is van de integriteit van de Trusted Computing Base (TCB), de versheid van extern bewijs en de kalibratie van validators. Zij merken op dat de prototype-resultaten workload-afhankelijk zijn en geen algemene prestaties garanderen, waarbij zij een incrementele implementatiestrategie suggereren die begint bij domeinen met hoge consequenties.