10110010011101001011001101101110101018200.devFrom Enterprise.Systems

Prevenție activă

8200.dev începe ca detectiv — observă, explică și acordă punctaje. Prevenția activă permite motoarelor să și acționeze: să elimine o legătură publică, să revoce o partajare riscantă, să reducă accesul, să suspende un agent renegat sau să revoce domeniul unui agent.

Acționarea este limitată, reversibilă și onestă. Acoperirea detectivă este în direct acum; scrierile preventive necesită OAuth cu domeniu de scriere explicit, sunt simulate în mod implicit și scriera vendor real este pasul final controlat de fondator.

Detectiv vs preventiv

Aplicarea detectivă — observă, explică, produce o verdictă — este în direct acum pe fiecare conector. Aplicarea preventivă acționează la vendor și este opțională per conector: activarea preveniției stabilește opțiunea per-conector (și, în modul mock, simulează acordul domeniului de scriere cu privilegii crescute, deci întreaga buclă este demo-abilă astazi).

Cinci acțiuni de remediere

Fiecare propunere se mapează la unul dintre cinci tipuri de acțiuni, fiecare purtând condițiile sale prealabile, apelul exact API-ului vendor pe care l-ar face și starea anterioară pe care o înregistrează pentru anulare:

  • Elimină legătura publică — scoate o partajare anonimă sau publică pe web.
  • Revocare partajare — elimină o subvenție externă sau de oaspete specifică.
  • Reducere acces — micșorează o permisiune prea largă (de exemplu, editor → vizualizator).
  • Suspendă principal — dezactivează o identitate renegată sau compromisă.
  • Revocare domeniu agent — retrage consimțământul prea larg al unui agent AI sau aplicație.

Cele patru niveluri de remediere

Alegeți cât de departe merge 8200.dev pentru a rezolva o constatare. Stabiliți un implicit la nivelul organizației și anulați-l per regulă în Politicile de securitate. Nivelurile formează o scară strict — fiecare adaugă capabilitate și, cu ea, raza de explozie.

8200.dev este doar citire implicit. Accesul de scriere vine doar dintr-un grant separat pe care îl aprobați — per repository pentru Fix-PR, per conector pentru Auto — și niciodată din conexiunea de monitorizare principală.

  1. 1Notificare (toate planurile) — o alertă plus un playbook de remediere. Nimic nu se schimbă. Acesta este implicitul.
  2. 2Reparație ghidată (planuri plătite) — comenzile exacte, o legătură directă la setările furnizorului pentru acea resursă și pașii. Tu le execuți pe partea ta; nu este necesar accesul de scriere.
  3. 3Fix-PR (Business și superior) — 8200.dev deschide o cerere de extragere reparatoare în repository-ul tău; un om o revizuiește și o fuzionează. Nimic nu se schimbă fără aprobare și necesită un grant de scriere separat, revocabil, per-repository.
  4. 4Auto (Business și superior) — pentru regulile pe care le alegi, 8200.dev aplică reparația automat sub salvagarziile auto-guard existente (comutator de ucidere, listă albă, opțiune per-conector).

Manual vs AUTO-GUARD

Remediera manuală este cu un singur clic: Simulează întotdeauna, Execută cu confirmare explicită atunci când prevenția este în direct. AUTO-GUARD opțional acționează automat asupra încălcărilor de înaltă încredere, deterministe — este dezactivat în mod implicit și disponibil pe tierul Business și superior.

AUTO-GUARD este fail-closed prin design: un verdict doar model nu poate declanșa niciodată o auto-execuție, doar o listă conservatoare de tipuri de acțiuni este eligibilă, iar un comutator de ucidere global bate orice poartă și degradează orice aplicare la simulate-only.

Simulat până la acordare

Până când OAuth cu domeniu de scriere nu este acordat și evaluat, fiecare acțiune rulează în modul simulat și este etichetată ca atare — nimic nu revendică o schimbare vendor în direct pe care nu a făcut-o. Aplicarea conectorului mock este reală și reversibilă față de graficul demo, marcată ca date demo.

Fiecare acțiune — simulată sau în direct — scrie o urmă de audit completă și reversibilă: cine, ce, când, înainte → după și rezultat.