Ingen beskyttet handling udføres uden en gyldig godkendelse.

4 roller (internal_admin, org_admin, approver, auditor) og 45 tilladelser, opregnet som data frem for spredt over `if`-udtryk, håndhæves ved hver konsolrute, før rutens kode køres.

Postgres Row-Level Security håndhæves på databasens ROLE-niveau, ikke kun i applikationens `WHERE`-filtre — produktion kræver et særskilt NOINHERIT-login, som ikke ejer databasen, og som med SET LOCAL ROLE skifter til en applikationsrolle uden superbruger- eller BYPASSRLS-rettigheder pr. transaktion. Før deployment afvises privilegerede driftslegitimationsoplysninger, og parathedskontrollen afviser adgang (503), hvis den effektive rolle kan omgå RLS.

Ekstra autentifikation er påkrævet før følsomme ændringer (eksport af revisionsspor, nøglerotation, håndtering af tillidsrødder, parring af enheder) og må højst være 10 minutter gammel. Som standard er det nok at indtaste din adgangskode igen. En organisation kan hæve sit minimumskrav til en passkey (WebAuthn) eller et nyt login gennem sin udbyder af fælles login.

OIDC (PKCE + nonce + state) og SAML (signaturkontrolleret, med cache til at afvise gentagelser).

SCIM v2, autentificeret med bearer-token og afgrænset til kunden, med kaskadevis fjernelse af adgang. Selve bearer-tokenet kan tilbagekaldes.

Revisionshændelser kan kun tilføjes, og hver hændelse henviser til den forriges hashværdi (sha256 af en kanonisk JSON-form). En eksport, der kræver ekstra autentifikation, indeholder konsollens eget genberegnede resultat af kædekontrollen sammen med dataene, så kundens revisor selvstændigt kan gentage kontrollen frem for at stole på vores erklæring. Eksportens begrænsning angives ærligt: højst 10.000 hændelser pr. eksport — over grænsen afviser ruten og henviser til SIEM-strømmen, som kan genoptages, frem for at afkorte i stilhed.

Hver kædes hoved kan signeres med en Ed25519-nøgle, der opbevares uden for databasen (eventuelt tidsstemplet af en ekstern RFC 3161-tjeneste), og sendes som NDJSON til kundens eget SIEM. Dette gør en senere omskrivning af en tidligere hændelse synlig for enhver, der har en kopi af forankringen — det forhindrer ikke i sig selv en omskrivning af en aktør, der har både databasen og signeringsnøglen. Inaktivt, indtil en operatør konfigurerer en signeringsnøgle; opfinder aldrig en forankring og afslutter aldrig i stilhed, som om en var oprettet.

Én kontrolleret bevispakke ad gangen, sendt som sine kanoniske bytes, så `sha256(exported file)` matcher en svarheader — læseren behøver ikke stole på en genberegning.

Den kanoniske Node-verifikator (node:crypto) til Ed25519 sammenlignes med erstatningsmodulet til browseren (@noble/curves), som dette websteds eget /playground bruger, mod 5 klasser af skadelige testvektorer (ændrede signaturer, som ligner ægte signaturer, svage nøgler, tal uden for intervallet, ugyldige nøgleformater og forkert formateret base64-tekst). Det sjette beviskort linker til en separat offentlig verifikatormatrix. Køres i dette websteds CI ved hvert push til main; testkoden er privat.

Afgrænset påstand, præcist formuleret: i mobilappens loginmateriale til e-mail-links lagres e-mailadressen kun som en hashværdi med nøgle, tokenet i loginlinket og sessionens bearer-token lagres som sha256-hashværdier, der sammenlignes i konstant tid, og sessionens identitet er et uigennemskueligt internt bruger-id. Konsollens kontoprofil lagrer selve din login-e-mailadresse, så vi kan drive din konto — se /privacy.

Relæpostkassen i drift lagrer den Gate-signerede anmodning om en afventende handling, dens DEFERRED-kvittering (registreringen af, at handlingen venter), godkendelsesvisningen krypteret til enhedens nøgle, enhedens signerede beslutning samt identifikatorer for agent, legitimationsoplysninger og Gate. Konsollen kan ikke læse visningen og giver aldrig godkendelse ud fra disse rækker. Udløbne rækker kan først slettes, når den længste af 30 dage og organisationens opbevaringsperiode er gået siden udløbet.

Oprydningsværktøjet bruger hver organisations konfigurerede opbevaringsperiode og sletter udløbet loginmateriale, gamle sikkerhedshændelser og udløbne rækker i relæpostkassen, som har passeret deres opbevaringsgrænse, ved en udtrykkelig --apply-kørsel (en prøvekørsel er standard). Det rører bevidst ikke selve revisionskæden, som kun kan tilføjes til.

RFC 9116 security.txt, maskinlæsbar, på standardstien til velkendte oplysninger.

Idempotente Postgres-migrationer med kontrolsummer, kørt mod en rigtig PostgreSQL 18-instans i CI før merge. Migrationsværktøjet afviser alle andre hovedversioner af serveren før kørsel.

En logisk gendannelsesprocedure, som afviser ved fejl, med indtjekkede øvelsesværktøjer: restore-drill.sh og særskilte verifikatorer til den gendannede migrationsbog, den gendannede revisionskæde og core-8-invarianterne. Den historiske øvelse registreret den 2026-08-29 gendannede en logisk produktionskopi bundet til en hashværdi i isoleret PostgreSQL 18 ved præcis version 060: 60 migrationer og 92 offentlige tabeller, hvor alle MVCC-tabelfingeraftryk og kontroller af revision og RLS/ACL bestod. Dens afgrænsede resultat er SEMANTIC_PASS_WITH_NON_MVCC_SEQUENCE_BOUNDARY, fordi PostgreSQL-sekvenser ikke blev sat i ro. Det beviser ikke, at udbyderens egne sikkerhedskopier kan gendannes, udbyderens PITR-konfiguration eller aktuelle driftstilstand eller produktionens RPO/RTO.

En automatisk parathedsvagt kører fra indtjekket kode: en planlagt arbejdsgang kontrollerer produktion, åbner én P1-hændelsessag uden dubletter ved fejl og lukker den efter bekræftet genopretning. Hyppigheden angives ærligt — GitHubs planlægger leverer efter bedste evne, så hver kørsel måler og rapporterer sit eget mellemrum siden forrige kontrol (observerede mellemrum på op til 2h35m oplyses i selve arbejdsgangen) frem for at påstå et interval på fem minutter, som den ikke kan overholde; et indtjekket script til ekstern kontrol kører den samme parathedskontrol og varsler ved fejl, hver gang en ekstern planlægger kalder det. Intervallet fastsættes af den planlægger, og ingen er endnu tilsluttet i produktion. Stadig åbent, klart nævnt: en planlægger med garanterede intervaller i produktion og en offentlig statusside. SIEM-eksporten ovenfor er fortsat vejen til kundens egen overvågning.