Ga naar hoofdinhoud
Audact
Bekijk het aanbod

Authority before action. Proof through finality.

Deze pagina beschrijft de bouw van het systeem. Ze is geschreven voor wie de response body leest en niet de folder.

Een verzoek wordt tegen een mandaat getoetst voordat er buiten het model iets gebeurt. De toetsing geeft één van drie antwoorden terug, en alle drie schrijven ze een compliancebon. Wat een derde uit die bon kan narekenen (zonder sleutel, zonder account en zonder toegang tot onze systemen), staat hieronder, veld voor veld. Deze pagina beschrijft de vorm waarin uw eigen systeem de poort aanroept; in de beheerde spraaktoepassing bedient Audact het pad en zit dezelfde toetsing daarin. De drie antwoorden en de bon veranderen daar niet mee.

01. Het pad van een verzoek

Van binnenkomst tot bon

Zeven stappen. Het gaat om de vierde: de toetsing loopt voordat de handeling de grens overgaat, en niet nadat ze is geland. Een systeem dat achteraf kijkt kan vertellen wat er misging. Een systeem dat vooraf toetst kan het tegenhouden. Al het andere op deze pagina volgt uit die volgorde.

Het pad van een verzoek

De toetsing staat vóór de handeling, niet erna.

  1. 01

    Het verzoek komt binnen

    Een spraakbeurt, een chatbeurt of een tool-aanroep van een agent vraagt iets met werking buiten het model.

  2. 02

    Het mandaat wordt bepaald

    Tenant, agent en land bepalen welk mandaat en welke regelset voor dit ene verzoek gelden. Waar een specifieke regel bestaat, wordt niet tegen de algemene getoetst.

  3. 03

    De handeling wordt beschreven

    De beoogde werking wordt in een gestructureerde vorm gezet: wat, voor wie, hoeveel, onder welke regels. Op dit punt is ze beschreven. Uitgevoerd is ze niet.

  4. 04

    De toetsing loopt

    Die beschrijving wordt getoetst aan het mandaat (plafond, bereik, looptijd) en aan de regelset van het land. Dit is de stap die vóór de handeling staat, en daar zit het hele verschil.

  5. 05

    Eén van drie antwoorden komt terug

    Toestaan, escaleren of weigeren. Er is geen vierde antwoord en geen half antwoord.

  6. 06

    Alleen toestaan gaat de grens over

    Bij toestaan voeren uw systemen de handeling uit binnen de getoetste grenzen. Bij de andere twee antwoorden wordt ze helemaal niet uitgevoerd.

  7. 07

    De bon wordt geschreven

    Invoerhash, uitvoerhash, de koppeling met de vorige bon en de ingang die in de Merkle-boom gaat. Dat gebeurt na elk van de drie antwoorden.

02. De poort

Eén aanroep. Drie antwoorden. Na elk een bon.

De poort is één aanroep die uw systeem doet op het punt waar een handeling anders zou beginnen. Ze antwoordt met één van drie uitkomsten en geeft in alle gevallen een compliancebon terug. Welk antwoord het ook wordt: dat er een bon wordt geschreven verandert daar niet door.

De drie uitkomsten van één poortaanroep

Drie antwoorden, één artefact.

De drie uitkomsten
  • Uitkomst
    Toestaan
    Wat er met de handeling gebeurt
    Wordt door uw systemen uitgevoerd, binnen de getoetste grenzen.
    Wat er terugkomt
    Compliancebon
  • Uitkomst
    Escaleren
    Wat er met de handeling gebeurt
    Tegengehouden. Gaat naar een mens, en die mens beslist.
    Wat er terugkomt
    Compliancebon
  • Uitkomst
    Weigeren
    Wat er met de handeling gebeurt
    Wordt niet uitgevoerd.
    Wat er terugkomt
    Compliancebon

Een weigering levert hetzelfde artefact op als een toestemming. Daar gaat het om: de vastlegging is geen lijst van wat er goed ging.

De vorm van de aanroep

Ter oriëntatie, niet als specificatie. De verwijzing veld voor veld staat in de API-documentatie.

Verzoek

POST /v1/gate/evaluate

{
  "tenant":  "acme-emea",
  "agent":   "renewals-emea",
  "intent":  "commit.discount",
  "country": "DE",
  "amount": {
    "value":    1240,
    "currency": "EUR"
  }
}

Antwoord

200 OK

{
  "outcome": "escalate",
  "reason":  "above the agent ceiling",
  "receipt": {
    "id":          "rcpt_01J8...",
    "input_hash":  "sha256:9f2a...",
    "output_hash": "sha256:41c7...",
    "prev":        "sha256:0b8e...",
    "auth":        "hmac-sha256",
    "merkle": {
      "root": "sha256:77d1...",
      "path": 4
    }
  }
}
Governance Gate-API

Waar een escalatie blijft staan

  1. Afgerond: Mandaat

    Door een mens gezet.

  2. Afgerond: Bevoegdheid

    Begrensd, niet open.

  3. Vraagt een mens: Vrijgave

    Deze ligt erboven.

  4. Nog niet begonnen: Werking

    Wat ze zou veroorzaken.

  5. Nog niet begonnen: Verplichting

    Wat eruit volgt.

  6. Nog niet begonnen: Definitiefheid

    Volgt uit afsluitbewijs van een bevoegde bron en is later na te rekenen.

Een escalatie mislukt niet en glipt er ook niet stilletjes doorheen. Ze stopt precies daar waar alleen een mens haar verder kan brengen. Deze zes stations ordenen het scherm en het gesprek; ze zijn een leeswijzer voor de toestand, geen als zodanig geclaimd mechanisme.

03. Faalgedrag

Wat er gebeurt als de bestuurslaag onbereikbaar is

Elke opzet van dit soort moet één vraag eerlijk beantwoorden: wat doet het systeem als het deel dat de bevoegdheid verleent er niet is? Er zijn twee mogelijke antwoorden, en maar één daarvan houdt de vastlegging betekenisvol.

Gedrag bij een bereikbare en bij een onbereikbare bestuurslaag

Geen antwoord geldt als geen bevoegdheid.

Normaal

De poort antwoordt

Eén van de drie uitkomsten komt binnen het toetsvenster terug. De handeling volgt het antwoord, en er wordt een bon geschreven.

Fail-closed

De poort antwoordt niet

Geen antwoord binnen het venster geldt als geen bevoegdheid. De handeling wordt niet uitgevoerd, de aanroeper krijgt een weigering in plaats van een stilte die als ja leest, en de onbereikbaarheid zelf wordt vastgelegd, zodat het gat achteraf zichtbaar is in plaats van onzichtbaar.

Het woord daarvoor is fail-closed. De omgekeerde opzet (eerst doen, later rechttrekken) is die waarbij een storing niet meer van een goedkeuring te onderscheiden is, en dat is precies wat dit ontwerp opgeeft. Het is een bewuste ruil: beschikbaarheid wordt uitgegeven zodat de vastlegging haar betekenis houdt.

04. De bewijsketen

De bon als datastructuur

Een bon is geen logregel met een mooiere naam. Het zijn vijf velden, en drie daarvan kan iedereen narekenen met niets anders dan de bon: zonder sleutel, zonder account, zonder toegang tot onze systemen. Een vierde, het Merkle-pad, heeft een gepubliceerde wortel nodig; die publicatie en het open eindpunt daarvoor zijn in ontwikkeling. Veld voor veld gelezen zegt ze precies wat het artefact draagt.

Bonketen en Merkle-boom

Elke bon wijst terug en omhoog: naar de vorige en naar de wortel waarvan de publicatie in ontwikkeling is.

De velden van een bon
  • Veld
    input_hash
    Wat erin staat
    Het verzoek precies zoals het is getoetst.
    Door een derde na te rekenen
    Zonder sleutel
  • Veld
    output_hash
    Wat erin staat
    De handeling precies zoals ze is vastgelegd.
    Door een derde na te rekenen
    Zonder sleutel
  • Veld
    prev
    Wat erin staat
    De hash van de vorige bon in dezelfde keten.
    Door een derde na te rekenen
    Zonder sleutel
  • Veld
    merkle
    Wat erin staat
    Het pad van deze bon naar de Merkle-wortel.
    Door een derde na te rekenen
    Zodra de wortels gepubliceerd zijn
  • Veld
    auth
    Wat erin staat
    HMAC-SHA256 onder een symmetrische sleutel per tenant.
    Door een derde na te rekenen
    Sleutel nodig

Drie velden, door iedereen na te rekenen

Invoerhash, uitvoerhash en de schakel naar de vorige bon: drie velden, na te rekenen met niets anders dan de bon. Zonder sleutel, zonder account, zonder toegang tot onze systemen. Een vierde, de plaats van deze bon in de Merkle-wortel, heeft een gepubliceerde wortel nodig om tegen af te zetten. Die publicatie en het open eindpunt daarvoor zijn in ontwikkeling. Het vijfde veld, de authenticatiecode, wordt berekend onder de symmetrische sleutel van die tenant en authenticeert de bon tegen die sleutel.

Juist dat narekenen maakt een latere wijziging aan een bon, of een herordening van de keten, aantoonbaar: de opnieuw berekende wortel past dan niet meer op de bewaarde.

Open de bonverkenner

05. Waar de data staat

Hosting, in de volgorde die telt

De primaire toepassingshosting staat in Frankfurt. De tabel zegt laag voor laag waar elk deel van het systeem draait en waar elke leverancier verwerkt.

Waar elke laag draait
  • Laag
    Toepassing en API
    Waar
    Frankfurt
    Toelichting
    Primaire toepassingshosting.
  • Laag
    Bewijsketen en bonnen
    Waar
    Frankfurt
    Toelichting
    Opgeslagen bij de tenant waar ze bij horen.
  • Laag
    Spraak-, model- en telefonieleveranciers
    Waar
    Per leverancier
    Toelichting
    Sommige verwerken buiten de EU onder standaardbepalingen.
  • Laag
    Merkle-wortels (publicatie in ontwikkeling)
    Waar
    Publiek eindpunt
    Toelichting
    Alleen hashes, geen persoonsgegevens.

De gezaghebbende lijst

Het Trust Center noemt elke subprocessor en waar die verwerkt, ook de partijen die in de Verenigde Staten verwerken onder standaardbepalingen. Die lijst wordt bijgehouden, is op dit punt gezaghebbend, en deze pagina volgt hem.

Bekijk de actuele productstatus

06. Wat het niet is

Drie dingen die het niet is, en de misverstanden die dat voorkomt

Dit zijn de drie aannames die het duurst uitpakken als niemand ze tegenspreekt: elk klinkt als een compliment, en elk beschrijft een ander product.

Geen aftaplaag in het verkeer

Niet dit

Niets van wat op deze pagina staat beschreven staat vóór uw netwerk, en niets hiervan leest uit zichzelf een datastroom van u mee.

De poort die hier beschreven staat is een aanroep die uw systeem doet, op een plek in uw eigen code die u zelf kiest. Roept uw systeem hem niet aan, dan wordt er niets getoetst – en niets vastgelegd. Dekking is een eigenschap van de plek waar u de aanroep zet, niet iets wat het netwerk u cadeau doet. De beheerde spraaktoepassing is de andere vorm: daar wordt de spraakstack door Audact bediend, dus zit de toetsing in een pad dat wij bedienen en niet bij een aanroep die u zet. Welke van de twee geldt, wordt per inzet vastgesteld.

Geen sleutelkluis voor uw systemen

Niet dit

Audact bewaart, roteert en verstrekt geen inloggegevens die uw systemen onderling gebruiken, en is geen plek om een sleutel te parkeren die u liever niet zelf beheert.

Eén sleutel wordt per tenant gehouden: die waaronder de authenticatiecode op de bon wordt berekend. Wat die sleutel dekt staat veld voor veld in hoofdstuk 04.

Geen grootboek

Niet dit

De keten is geen rekeningenboek. Er staan geen saldi in, er gaat geen geld doorheen, en er wordt niets tussen twee partijen verrekend.

Hij legt vast wat er is besloten en wat daaruit volgde. Geld beweegt in uw eigen systemen; de bon zegt wat er mocht en wat er is vastgelegd, en blijft uit de boekhouding.

Verder

Reken het zelf na

De snelste manier om deze architectuur te beoordelen is niet verder lezen. Neem een bon, reken de keten veld voor veld na en zie zelf dat het klopt.

De mechanismen die op deze pagina staan horen bij een patent-pending governance stack (UK IPO).