Sikkerhet og styring

Token

Tilgang er et bearer-token som utstedes per virksomhet fra portalen. AiAx viser klarteksten én gang og lagrer bare en hash av den, slik at en kopi av databasen vår ikke gir et fungerende token. Et token kan trekkes tilbake umiddelbart og kan ha en utløpsdato.

• Ett token hører til nøyaktig én virksomhet. Det finnes ingen token på tvers av virksomheter.
• Tilbaketrekking og utløp håndheves når tokenet slås opp, ikke som et filter etterpå.
• Et token ser slik ut: brain_xxxxxxxxxxxxxxxxxxxxxxxx. Behandle det som et passord: legg det i sikker lagring, aldri i et kodelager.
• Endepunktet ratebegrenser per adresse før det i det hele tatt slår opp et token, slik at det koster en angriper mer å prøve seg enn det koster oss.

Tilgangsnivået bestemmer hva som er synlig

Hvert token har et tilgangsnivå. Nivået bestemmer hvilken kunnskap tokenet får se, ved hver eneste lesing, og treff over nivået returneres aldri. Et søk som støter på kunnskap over nivået, forteller bare hvor mange treff som ble skjult.

Noder klassifiseres med ett av disse tilgangsnivåene: public, department, project, manager, hr, executive, restricted. En relasjon er synlig bare når begge nodene den binder sammen er synlige, slik at formen på grafen ikke kan lekke det innholdet skjuler.

Scopes bestemmer hva som kan kalles

Et token har også scopes, uavhengig av tilgangsnivået. Scopene bestemmer hvilke klasser av verktøy tokenet får kalle, og de feiler lukket: en lagret kapabilitet som ikke lar seg tolke rent, avvises i stedet for å falle tilbake til et standardsett.

brain:read

Kreves av alle leseverktøy. Finnes på alle token, fordi et token som ikke får lese noe, ikke er til nytte.

brain:propose

Kreves i tillegg av alle forslagsverktøy for kunnskap. Gis eksplisitt, aldri som standard. Uten det blir et forslagskall avvist, og ingenting registreres.

outreach:propose

Kreves av propose_draft_email, og av ingenting annet. Gis på toppen av forslagsscopet og aldri av det, slik at et token som kan foreslå kunnskap, ikke kan foreslå kundevendt e-post uten at dette scopet er gitt i tillegg. Det gir rett til å foreslå et e-postutkast som en leder må godkjenne. Det sender aldri, og det leser aldri e-post.

Leseverktøyene er merket read-only i selve protokollen, slik at en klient som følger protokollen, vet før den kaller at de ikke kan endre noe. De skriver aldri til kunnskapsgrafen.

Forbidden: this token is missing the required brain:propose scope. The proposal was NOT registered.

Godkjenningsinnboksen

Ingenting eksternt skriver til grafen. Et forslag fra en agent blir et element i innboksen i portalen, med type, tittel, innhold og hvilke node-ider det gjelder. En leder leser det og bestemmer.

• Beslutningen bindes til det lagrede forslaget. En manipulert klient kan ikke smugle inn annet innhold forbi godkjenningen.
• Innholdet i forslaget valideres når det kommer inn, som alle andre data utenfra.
• Skrivevolum er ratebegrenset per token og per virksomhet. En avvisning sier rett ut at ingenting ble registrert.
• Det er godkjenningen som utleder grafen på nytt. Før det er hjernen uendret.

Write rate limit reached for this token or organization. The proposal was NOT registered. Try again later.

Ferskhet over tid

Kunnskap forfaller. Hver verifiserte kilde registrerer når et menneske sist bekreftet den og hvor lenge bekreftelsen varer. Når vurderingsvinduet går ut, er kilden foreldet, og systemet sier fra i stedet for å servere gamle svar i stillhet.

1. Et menneske verifiserer en kilde. Det registrerer et verifiseringstidspunkt og starter et vurderingsvindu.
2. Når vinduet går ut, rapporteres kilden som foreldet overalt der den vises, også i gap-listen agentene leser.
3. Et vurderingsforslag reises i godkjenningsinnboksen og ber et menneske bekrefte kunnskapen på nytt.
4. Godkjenning registrerer et ferskt verifiseringstidspunkt og starter vinduet på nytt.

Å avvise en vurdering utsetter den, den fjerner den ikke. Kilden står som foreldet gjennom hele utsettelsen, så grensesnittet skjuler aldri sannheten. Bare påminnelsen hviler, og den kommer tilbake når utsettelsen er over.

Sletting

Sletting må nå de avledede kopiene, ellers er det ikke sletting. To garantier betyr noe for en kunde.

Å koble fra en kilde

De lagrede tilgangene til kilden slettes umiddelbart. Innhentingen stopper med én gang, og å koble til igjen krever en ny autorisasjon.

Å fjerne en person

Når en person fjernes fra organisasjonskartet, eller feltene som former grafen endres, slettes alt virksomheten har avledet, i samme databasetransaksjon: søkevektorene, de bufrede sammendragene og hele historikken av kompilerte ferdighetspakker. Ingen avledet kopi av personen overlever endringen, heller ikke navnet inne i en bevart revisjon av en ferdighetspakke.

Avledede lagre bygges opp igjen fra den levende grafen ved neste autoriserte lesing, slik at sletting koster ferskhet og ikke tilgjengelighet. En formell sletteforespørsel kjører i tillegg den dokumenterte personvernprosessen i begge databasene våre: en forhåndsvisning av nøyaktig hva som omfattes før noe endres, og en verifisering etterpå som viser at identifikatorene gir null treff i hvert eneste slettede lager.

Tilgangene til tilkoblede kilder oppbevares kryptert. Revisjonssporet beholder identifikatorer, hasher, tilstander og antall, aldri meldingsinnhold eller kunnskapsinnhold.