# Skrev en avgrensningsregel inn i repoet etter at en omstrukturering hadde ført et annet selskaps inventar, brannmuråpninger og tekst inn i det — og holdt de karantenesatte restene under skanneren for hemmeligheter i stedet for å unnta dem. september 2026 **Situasjon.** Arbeid gjort for et annet selskap fulgte med gjennom en omstrukturering av repoet og ble liggende. Det som fulgte med, var ikke abstrakt: en kladdelogg med gyldige påloggingsopplysninger i klartekst, som lå i treet forbi alle sperrer gjennom det meste av repoets historikk; en utdatert inventarfil som navnga det selskapets vert; og en oppgavefil for brannmuren som åpnet porter for seksten av det selskapets kundenettverk. Ingenting av det kjørte. Det er nettopp derfor det overlevde — noe som ikke kjører noe sted, blir aldri gjennomgått igjen. **Oppgave.** Grensen måtte bli en regel med en test knyttet til seg, ikke en intensjon, og restene måtte håndteres på en måte som ikke bare skjulte dem. **Handling.** Regelen er nå den innledende seksjonen i repoets instruksjonssett: dette repoet forvalter ett selskaps infrastruktur og bare den, og en annen parts vert, inventar, brannmuråpning, DNS‑sone eller påloggingsopplysning hører ikke hjemme i det — ikke engang deaktivert, kommentert ut eller parkert i en fil ingen playbook importerer. Den praktiske testen står skrevet ved siden av: ville dette selskapet fortsatt være ansvarlig for dette hvis forholdet tok slutt. Restene ble satt i karantene i en tydelig navngitt katalog i stedet for å bli slettet, slik at historikken forblir lesbar, og karantenen er bevisst delvis — de to strukturelle linterne hopper over den, mens hemmelighetsskanneren, vault‑vakten og emoji‑sjekken med vilje fortsatt leser den, fordi det er de tre som ville fange det som slapp inn. Selve lekkasjen ga en linterregel: et egendefinert mønster som flagger en påloggingsopplysning som sendes som et kommandolinjeflagg, som er formen den lekkede hadde, og som standardregelsettet ikke fanget. **Resultat.** Omfangsgrensen er en skriftlig regel med en oppgitt test, restene er synlige i stedet for begravd, og den konkrete formen for påloggingsopplysning som slapp gjennom, får nå en commit til å feile. Lærdommen som er dokumentert ved siden av, er den generelle: den farlige artefakten er ikke den som kjører, men den som ikke gjør det, fordi det er den ingen leser igjen. --- - Rolle: Sikkerhetsingeniør - Kategorier: [Datastyring](https://advisory.engineer.company/nb/categories/data-governance/), [Infrastruktur](https://advisory.engineer.company/nb/categories/infrastructure/), [Automatisering og CI/CD](https://advisory.engineer.company/nb/categories/automation/), [Sikkerhet](https://advisory.engineer.company/nb/categories/security/), [Dokumentasjon](https://advisory.engineer.company/nb/categories/documentation/) - Tjenester: [Datastyring og datakvalitet](https://advisory.engineer.company/nb/services/data-governance/), [Sikkerhet og tilgangsstyring](https://advisory.engineer.company/nb/services/security-access/), [Teknisk dokumentasjon](https://advisory.engineer.company/nb/services/technical-documentation/)