Prevenção ativa

Detetivo vs preventivo

A aplicação detetiva — observar, explicar, produzir um veredito — está ativa agora em todos os conectores. A aplicação preventiva atua no fornecedor e é opcional por conector: ativar a prevenção define a adesão por conector (e, em modo fictício, simula a concessão de âmbito de escrita elevado, para que todo o ciclo seja demonstrável hoje).

Cinco ações de remediação

Cada proposta corresponde a um de cinco tipos de ação, cada um com as suas precondições, a chamada de API exata ao fornecedor que efetuaria e o estado anterior que regista para anulação:

• Remover ligação pública — eliminar uma partilha anónima ou na web pública.
• Revogar partilha — remover uma concessão específica externa ou de convidado.
• Reduzir acesso — diminuir uma permissão demasiado abrangente (por exemplo, editor → visualizador).
• Suspender principal — desativar uma identidade desonesta ou comprometida.
• Revogar âmbito do agente — retirar o consentimento demasiado abrangente de um agente de IA ou de uma aplicação.

Os quatro níveis de correção

É o utilizador que decide até que ponto o 8200.dev atua para corrigir uma constatação. Defina uma predefinição para toda a organização e substitua-a por regra nas Políticas de Segurança. Os níveis formam uma escala rigorosa — cada um acrescenta capacidade e, com ela, o raio de impacto.

O 8200.dev é de apenas leitura por defeito. O acesso de escrita provém exclusivamente de uma concessão separada aprovada pelo utilizador — por repositório para Fix-PR, por conector para Auto — e nunca da ligação principal de monitorização.

1. 1Notificar (todos os planos) — um alerta acompanhado de um manual de correção. Nada é alterado. Esta é a predefinição.
2. 2Correção guiada (planos pagos) — os comandos exatos, uma ligação direta às definições do fornecedor para esse recurso e os passos a seguir. É o utilizador que os executa do seu lado; não é necessário qualquer acesso de escrita.
3. 3Fix-PR (Business e superiores) — o 8200.dev abre um pull request de correção no seu repositório; uma pessoa revê-o e integra-o. Nada é alterado sem aprovação, e requer uma concessão de escrita separada, revogável e por repositório.
4. 4Auto (Business e superiores) — para as regras que escolher, o 8200.dev aplica a correção automaticamente ao abrigo das salvaguardas existentes do auto-guard (kill-switch, lista de permissões, autorização por conector).

Manual vs. AUTO-GUARD

A remediação manual faz-se com um clique: Simular sempre, Executar com confirmação explícita quando a prevenção está ativa. O AUTO-GUARD pode, opcionalmente, agir automaticamente apenas sobre violações determinísticas e de elevada confiança — está desativado por predefinição e disponível no plano Business e superiores.

O AUTO-GUARD é fail-closed por conceção: um veredicto exclusivamente baseado no modelo nunca pode despoletar uma execução automática, apenas uma lista de permissões conservadora de tipos de ação é elegível, e um kill-switch global prevalece sobre todas as barreiras e reduz toda a aplicação a apenas simulação.

Simulado até ser concedido

Até que o OAuth com âmbito de escrita seja concedido e avaliado, todas as ações são executadas em modo de simulação e identificadas como tal — nada reivindica uma alteração real ao fornecedor que não tenha efetuado. A aplicação por conector simulado é real e reversível contra o grafo de demonstração, identificada como dados de demonstração.

Todas as ações — simuladas ou reais — registam um rasto de auditoria completo e reversível: quem, o quê, quando, antes → depois, e resultado.