Ladan · Översikt Säkerhet & efterlevnad

Granskningsbar och isolerad, i er kontroll.

Offentlig sektor måste kunna visa vem som gjorde vad, hur data behandlades och att inga uppgifter läckte. Ladan är byggd för det. Varje ändring loggas, känsliga uppgifter döljs och modellens kod körs isolerat, allt i er egen drift.

Avstängt från start OAuth 2.1 mot er egen IdP AES-256-kryptering
Spårbarhet

Två lager insyn: ett för driften, ett för revisorn

Ladan skiljer på drift och efterlevnad. OpenTelemetry visar tjänstens aktuella hälsa. Granskningsloggen ger en oföränderlig post över varje ändring, redo för granskning. Båda är avstängda från start.

  • Hash-länkad granskningslogg. Varje ändring kedjas till den föregående, och rader kan endast läggas till. Om en rad ändras i efterhand syns det direkt, och raden visar alltid vem som gjorde vad.
  • Automatisk maskning. Personnummer, e-post och andra känsliga uppgifter döljs innan något loggas.
  • Kostnad per anrop. Varje modellanrop bokförs med sin kostnad, så ni ser vad sökning och svar faktiskt kostar.

Ladan binder er inte till en leverantör. Spåren går till vilket system ni redan kör, och granskningsloggen stannar i er egen databas.

Identitet & åtkomst

Vem som frågar, och vad de får se

Operatörer styrs av roller. Varje MCP-server väljer sitt eget inloggningsläge. Bakom en integration kan Ladan känna igen den faktiska användaren, utan att personen behöver ett eget konto.

Inloggningsläge
static_bearer maskin-till-maskin
oauth OAuth 2.1
Token
En hashad bärartoken, skapad vid servern.
En signerad token som verifieras mot er inloggningsleverantör.
Identitet
Ingen slutanvändare, en tjänst anropar.
Anroparens identitet och behörighet når varje verktyg.
IdP
Vilken OIDC-leverantör som helst: Keycloak, Entra, Auth0, Okta.
Använd när
Cron, provisionering, en värds egen administrationsväg.
Anropet ska veta vilken människa som frågar.
  • Roller & behörigheter. Administratör, redaktör och läsare, kontrollerat vid varje anrop och inte endast i gränssnittet.
  • Behörighetstak per nyckel. Varje API-nyckel begränsas till exakt de servrar, samlingar och förmågor den ska ha åtkomst till, aldrig bredare.
  • Behörighet per användare. Ladan styr vad slutanvändaren får se utifrån identiteten som integrationen skickar med, utan ett lagrat användarkonto.
Tillitsnivå per anrop
noneIngen slutanvändare. Maskin till maskin.
assertedIdentitet påstådd av integrationen.
verifiedKryptografiskt verifierad inloggning. Går inte att förfalska.

Varje nyckel anger en lägsta tillitsnivå. Påstådd identitet når högst asserted, medan verified kräver en OAuth-server.

Isolering

Krypterat i vila, isolerat i körning

Hemligheter krypteras med en nyckel ni äger. Och koden modellen skriver, SQL över ett kalkylark eller JavaScript i kodläge, körs i en sandlåda utan åtkomst till filsystemet, internet eller andra samlingar. Varje organisation kör sin egen instans: er modell, er data, er server.

Krypterade hemligheter

API-nycklar och inloggningar lagras krypterade med AES-256. Krypteringsnyckeln levererar ni själva. Tappas den bort går inget att återställa, och det är meningen.

Isolerad SQL

Varje fråga mot ett kalkylark körs i en egen, tillfällig databas som endast tillåter läsning. En tabell, inga sidoeffekter.

Isolerat JavaScript

Kodlägets run_code kör i en sandlåda utan åtkomst till internet, filsystemet eller andra samlingar. Endast de verktyg ni kopplat in.

Efterlevnad

Slå på precis det ni behöver.

Allt är avstängt från start. Läs hur granskningslogg, spårbarhet och OAuth sätts upp, och aktivera det er efterlevnad kräver.