Förtroende & säkerhet

Varje webbplatsinloggning, API-token, TOTP-nyckel och insamlad sessionscookie förseglas med envelope-kryptering per kund:

• En 256-bitars datakrypteringsnyckel (DEK) genereras för varje organisation och används för att AES-256-GCM-kryptera hemligheten lokalt.
• Själva DEK:n omsluts av en nyckelkrypteringsnyckel (KEK) som förvaras i Google Cloud KMS. Den uppackade DEK:n lämnar aldrig applikationsprocessen; KEK:n lämnar aldrig KMS.
• Lagrad chiffertext är självbeskrivande (v2:<keyId>:…), så nycklar kan roteras utan att varje rad behöver läsas om.
• En databasdump ger i sig inga inloggningsuppgifter — återställning kräver KMS-åtkomst till kundens KEK.
• BYOK finns för företagskunder: registrera en Cloud KMS-nyckel i ditt eget GCP-projekt och ge vårt tjänstekonto kryptera/dekryptera på den. Vi omsluter organisationens DEK med din KEK, och du kan återkalla vår åtkomst när som helst. Konfigureras av organisationens ägare från organisationsinställningarna.

LLM-anrop är en uppenbar punkt där data lämnar systemet. Varje organisation styr, från sina inställningar:

• Avstå från LLM-spårning — prompts och svar skickas aldrig till våra observerbarhetsverktyg för den här kunden.
• Avstå från tredjeparts-omrankning — hämtat innehåll stannar internt och skickas aldrig till en omrankningsleverantör.
• Maskering av personuppgifter före utskick — e-postadresser, telefonnummer, nationella ID (inkl. svenska personnummer och amerikanska SSN), IPv4-adresser och betalkortsnummer rensas från prompttexten innan den når någon LLM-leverantör.

Standardvärdena bevarar nuvarande beteende; företag väljer själva den striktare hållningen utan att ändra någon applikationskod.

Varje tabell tillämpar Postgres Row Level Security. Användare ser bara sina egna rader, eller rader som tillhör en organisation de är medlem i. Ett organisationsmedlemskap har fyra roller (owner, admin, member, viewer); organisationsbaserade policyer läggs till ovanpå policyerna för personligt ägande.

Tjänsterollen (som kringgår RLS) är begränsad till serverkod som verkligen behöver den — t.ex. för att dekryptera inloggningsuppgifter i samma stund som en körning startar.

Kunderna väljer hur Bacheon autentiserar mot sina portaler. Vi behöver aldrig — och för SSO/MFA-webbplatser får vi aldrig — kundens primära lösenord:

• Lösenord — krypterat användarnamn och lösenord, valfritt med TOTP som andra faktor.
• API-token — krypterad token som skickas som en HTTP-header.
• Interaktiv session — cookies och lagring som samlas in efter att användaren själv loggat in i en live-webbläsare. Hanterar SSO, MFA, captcha och magiska länkar.

Varje kund kan konfigurera lagringstider. Standardvärden:

• Rådata för mätvärden — 30 dagar
• Aggregerade sammanställningar — 365 dagar
• Skärmbilder — 7 dagar (medvetet kort)
• AI-rapporter — 365 dagar
• Chatthistorik — 365 dagar

Ett schemalagt jobb upprätthåller dessa tider; utgången data raderas permanent.

SOC 2 Type II är en granskad attestering, inte en funktion: det kräver att en revisor observerar kontrollerna under ett fönster på 6–12 månader. Vi har ingen i dag. Vi arbetar SOC 2-redo och det formella uppdraget pågår.

GDPR — vi tecknar ett personuppgiftsbiträdesavtal med varje kund, upprätthåller listan över underbiträden ovan och hanterar raderingsbegäranden från registrerade via lagringspipelinen.

Ingen lagring genom konfiguration — chattvägen stänger av serverlagring hos OpenAI, så ingen kopia av prompter eller svar sparas där. Den enda lagringen hos leverantören är prompt-cachen: 30 minuter på standardmodellen, 24 timmar på äldre modeller. Längre lagring hos enskilda leverantörer regleras av deras företagsvillkor, som vi bekräftar innan vi behandlar kunddata via dem.