10110010011101001011001101101110101018200.devFrom Enterprise.Systems
Börja gratis

Aktiv förebyggande

8200.dev startar med detektiv — det observerar, förklarar och bedömer. Aktiv förebyggande låter motorerna även agera: ta bort en offentlig länk, återkalla en riskabel delning, nedgradera åtkomst, pausa en illvillig agent eller återkalla en agents scope.

Att agera är begränsat, reversibelt och ärligt. Detektivtäckning är live idag; förebyggande skrivningar kräver explicit write-scope OAuth, simuleras som standard, och den verkliga leverantörens skrivning är det slutliga steg som grundaren gatekeeper.

Detektiv kontra förebyggande

Detektivövervakning — observera, förklara, fatta ett beslut — är live nu över alla kopplingspunkter. Förebyggande övervakning agerar hos leverantören och är opt-in per kopplingspunkt: att aktivera förebyggande anger per-kopplingspunkt opt-in (och, i simuleringsläge, simulerar den upphöjda write-scope-tilldelningen så att hela loopen är demonstrerbar idag).

Fem åtgärder för åtgärdande

Varje förslag mappar till en av fem åtgärdstyper, var och en med dess förutsättningar, det exakta API-anrop hos leverantören det skulle göra, och det tidigare tillståndet det registrerar för undo:

  • Ta bort offentlig länk — ta bort en anonym eller offentlig webdelning.
  • Återkalla delning — ta bort en specifik extern eller gästbehörighet.
  • Nedgradera åtkomst — reducera en alltför bred behörighet (till exempel redigerare → visare).
  • Pausa huvudnamn — inaktivera en illvillig eller komprometterad identitet.
  • Återkalla agentscope — dra tillbaka en AI-agents eller apps alltför breda samtycke.

De fyra åtgärdsnivåerna

Du väljer hur långt 8200.dev går för att åtgärda ett fynd. Ställ in en organisationsomfattande standard och åsidosätt den per regel i Säkerhetsprinciper. Nivåerna bildar en strikt stege — var och en lägger till kapacitet och, med det, sprängningsradie.

8200.dev är skrivskyddad som standard. Skrivåtkomst kommer endast från en separat beviljande du godkänner — per databas för Fix-PR, per kopplingspunkt för Auto — och aldrig från kärnövervakaningskopplingen.

  1. 1Meddela (alla planer) — en varning plus en åtgärdsspelbok. Ingenting ändras. Det här är standard.
  2. 2Guidad korrigering (betalda planer) — de exakta kommandona, en direkt länk till leverantörens inställningar för den resursen, och stegen. Du kör dem på din sida; ingen skrivåtkomst krävs.
  3. 3Fix-PR (Business och uppåt) — 8200.dev öppnar en åtgärdande pull request i din databas; en människa granskar och sammanfogar den. Ingenting ändras utan godkännande, och det behöver en separat, återkallningsbar, per-databas-skrivbeviljande.
  4. 4Auto (Business och uppåt) — för de regler du väljer, tillämpar 8200.dev korrigeringen automatiskt enligt befintliga auto-guard-skyddsåtgärder (kill-switch, allowlist, per-kopplingspunkt opt-in).

Manuell kontra AUTO-GUARD

Manuell åtgärdande är ett klick: simulera alltid, kör med explicit bekräftelse när förebyggande är live. AUTO-GUARD kan valfritt auto-agera på höga-konfidens, deterministiska överträdelser endast — det är av som standard och tillgängligt på Business-nivå och högre.

AUTO-GUARD är fail-closed enligt design: en endast modellbaserad bedömning kan aldrig utlösa en auto-körning, endast en konservativ allowlist av åtgärdstyper är berättigad, och en global kill-switch slår varje gate och nedgraderar all övervakning till endast simulering.

Simulerad tills beviljad

Tills write-scope OAuth är beviljad och bedömd, körs varje åtgärd i simuleringsläge och är märkt som sådan — ingenting hävdar en live-leverantörsändring som det inte gjorde. Mock-kopplingspunktövervakning är verklig och reversibel mot demografen, märkt som demodata.

Varje åtgärd — simulerad eller live — skriver ett fullständigt, reversibelt granskningsspår: vem, vad, när, före → efter, och resultat.