Modelo de Segurança
Arquitetura técnica da proteção da Tríade Letal.
O Edison Watch previne a exfiltração de dados detectando e bloqueando a combinação de capacidades necessárias para um ataque.
A Ameaça: Injeção de Prompt
Agentes de IA são vulneráveis à injeção de prompt - instruções maliciosas escondidas em conteúdo externo (como uma página web ou arquivo) que manipulam a IA para exfiltrar dados sensíveis.
A Tríade Letal
A exfiltração requer três capacidades. O Edison Watch rastreia essas via bandeiras monotônicas por sessão:
| Capacidade | Bandeira de Segurança | Ação |
|---|---|---|
| Acesso a Dados Privados | read_private_data | IA lê arquivos internos, BDs ou documentos. |
| Conteúdo Não Confiável | read_untrusted_public_data | IA busca dados da internet. |
| Comunicação Externa | write_operation | IA envia dados para fora (Slack, Email, APIs). |
Lógica de Aplicação: Se uma sessão acessou tanto Dados Privados QUANTO Conteúdo Não Confiável, qualquer Comunicação Externa subsequente é pausada para aprovação humana.
Estado da Sessão
O estado é rastreado no servidor Edison e é monotônico: uma vez que uma bandeira é definida (ex: Dados Privados acessados), ela não pode ser removida para aquela sessão. Isso previne ataques de "reset".
Níveis de Controle de Acesso (ACL)
ACLs previnem que dados sensíveis fluam para destinos de menor sensibilidade, independentemente do estado da Tríade.
| Nível | Regra |
|---|---|
| PÚBLICO | Pode fluir para qualquer lugar. |
| PRIVADO | Não pode fluir para PÚBLICO. |
| SECRETO | Não pode fluir para PRIVADO ou PÚBLICO. |
Exemplo: Se um agente lê um banco de dados marcado como SECRETO, ele é imediatamente bloqueado de postar em um canal do Slack PÚBLICO.
Rastreamento de Dados
| Tipo de Dado | Registrado | Retenção (Padrão) |
|---|---|---|
| Chamadas de Ferramenta | Metadados & Parâmetros | 90 Dias |
| Resultados | Saída Truncada | 90 Dias |
| Eventos de Segurança | Mudanças de bandeira & Bloqueios | 1 Ano |
| Aprovações | Decisões do usuário | 1 Ano |
Privacidade: Conteúdos de arquivos brutos e históricos completos de conversas não são rastreados ou armazenados nos servidores Edison.
Criptografia de Credenciais
O Edison usa criptografia de conhecimento zero para credenciais armazenadas. Nenhuma chave de criptografia é armazenada no servidor.
| Tipo de credencial | Criptografado com | Chave armazenada? |
|---|---|---|
| Credenciais de usuário | Chave pessoal do usuário | Nunca -- apenas hash |
| Credenciais de admin | Chave de domínio (opcional) | Nunca -- apenas hash |
A chave do usuário é uma composição de segmentos digitados: user:{personal_key}.admin:{domain_key}. Cada segmento deriva chaves de criptografia via HKDF com prefixos distintos, garantindo separação criptográfica. Veja o Guia do Administrador: Criptografia de Credenciais para instruções de configuração.
Transporte & Autenticação
- Auth: Chaves de API assinadas com HMAC ou SAML 2.0/OIDC.
- Transporte: TLS 1.2+ obrigatório.
- Isolamento: Clientes se comunicam apenas com o servidor Edison; sem acesso direto do cliente aos backends MCP.
Fixação de Dependências (Dependency Pinning)
O Edison Watch previne ataques à cadeia de suprimentos fixando automaticamente dependências de servidores MCP na primeira execução.
Propósito
Servidores MCP instalados via executores de pacotes (npx, uvx) podem ser vulneráveis a ataques à cadeia de suprimentos se as dependências forem atualizadas maliciosamente. A fixação garante:
- Execução reproduzível: O mesmo código exato roda todas as vezes
- Resistência a adulteração: Lockfiles são armazenados com segurança e não podem ser modificados sem ação do admin
- Controle de versão: Versões exatas de pacotes são bloqueadas, prevenindo atualizações inesperadas
Como Funciona
-
Resolução na Primeira Execução: Quando um servidor usando
npxouuvxé montado pela primeira vez, o Edison Watch:- Resolve o grafo completo de dependências transitivas
- Gera um lockfile (npm:
package-lock.json, Python:uv.lock) - Armazena o lockfile com segurança no banco de dados local
-
Runtime Efêmero: Em cada montagem:
- Cria um diretório de runtime temporário
- Instala dependências a partir do lockfile armazenado (não de registros de pacotes)
- Executa o servidor a partir do ambiente de runtime isolado
-
Falha-Fechada: Se a fixação falhar (problemas de rede, lockfile corrompido), o servidor não iniciará. Isso garante que nenhum código não fixado seja executado.
Controles de Admin
Todo o gerenciamento de fixação é feito através do dashboard de admin:
- Ver Status: Veja versões de pacotes fixados e datas na visão geral do servidor
- Limpar Fixação: Remova lockfile em cache para forçar re-fixação (útil após atualizações de pacote)
- Limpar Todas as Fixações: Operação em massa para limpar todas as fixações de servidor
Nenhuma configuração de linha de comando ou variável de ambiente é necessária - todos os controles são via UI para segurança e auditabilidade.