Praktikanten
Sikkerhed

Det, en revisor spørger om. Og svarene.

Praktikanten er bygget som et sikkerhedslag, ikke som en integration med et sikkerhedsafsnit. Her er, hvordan det konkret er gjort.

Adgang gives i forretningsbidder, aldrig som ét token

En AI, der får et almindeligt API-token, kan alt, tokenet kan. Hos os findes tokenet kun hos os, krypteret, og AI'en får i stedet en liste af værktøjer: "find kunde", "opret fakturakladde", "hent saldobalance". Hvilke værktøjer den ser, afgøres af fem lag oven på hinanden:

  1. Kataloget — hvad systemet overhovedet kan, og om det læser eller skriver.
  2. Abonnementet — hvad jeres plan giver adgang til.
  3. Forbindelsen — hvad administratoren godkendte hos systemet.
  4. Rollen — en kigger kan aldrig skrive, uanset hvad der er tildelt.
  5. Medarbejderen — ingen, læs eller skriv pr. gruppe, sat af jeres administrator.

Det laveste lag vinder altid. Og et værktøj, medarbejderen ikke må bruge, bliver ikke afvist — det findes ganske enkelt ikke for AI'en. En assistent, der kan se en knap, den ikke må trykke på, bliver ved med at prøve.

Hvert kald går gennem tolv trin, hver gang

Token, abonnement, medlemskab, værktøj, rettighedsniveau, argumenter (beløb, sider, påkrævede felter), tempo, tidsvindue, godkendelse, udførelse, maskering, audit. Kæden kører på selve værktøjskaldet — ikke på teksten i samtalen. Derfor kan en manipulerende e-mail i bilagsindbakken eller en forgiftet note i den fælles viden bede om hvad som helst; den får kun det, lagene tillader.

Et menneske siger ja til det, der ændrer regnskabet

Bogføring kræver som udgangspunkt godkendelse af en medarbejder i portalen. Køen viser, hvad der konkret ville ske, argument for argument, og rettighederne beregnes forfra på den, der bad om det — ikke på den, der godkender. Den, der godkender, skal selv have skriveadgang til området. Anmodninger udløber efter et døgn.

Alt logges. Særligt det, der blev afvist

Audit-loggen har hvert kald med tidspunkt, medarbejder, værktøj, afgørelse og hvilket trin i kæden der afviste. Loggen overlever, at forbindelser og brugere slettes. Persondata i argumenterne maskeres, før de gemmes.

2-faktor, uden kodeord

Der er ingen kodeord at lække. Man logger ind med en engangskode, der kun virker i den browser, der bad om den, og 2-faktor med authenticator-app er tvunget, før et system kan forbindes eller Claude gives adgang. En stjålet e-mailkonto er ikke nok.

Tokens til systemerne forlader aldrig serveren

Adgangsnøgler til e-conomic og 2-faktor-hemmeligheder krypteres med libsodium og en nøgle, der kun findes på serveren. Databasen alene kan ikke bruges til noget. Afbrydes en forbindelse, slettes nøglen, og alle Claude-tokens mod den spærres i samme sekund.

Bilag rører aldrig samtalen

En PDF sendes ikke gennem AI'en som tekst. Filen ligger hos os, uden for webserverens rækkevidde, teksten trækkes ud på serveren, og AI'en får et id og noget tekst. Skal en fil ind i regnskabet, sker overførslen server til server.

Hosting i Danmark, uden mellemled

Platformen kører på egen server i Danmark med egen database, der ikke er tilgængelig udefra. Der er ingen tredjeparts-analyse, ingen sporing og ingen cookies ud over den, der holder dig logget ind.

Kill-switch

Én knap afbryder forbindelsen og spærrer alle tokens. Et enkelt Claude-token kan spærres for sig. Organisationen kan sættes på pause, så hvert kald afvises i trin to af kæden — og logges.

Læs også privatlivspolitikken og databehandleraftalen, som beskriver de tekniske og organisatoriske foranstaltninger formelt.

Se det i audit-loggen

Opret en konto, forbind e-conomic, og prøv at bede Claude om noget, den ikke må.