Esta documentação se refere às implantações federais do Devin. Voltar para a Documentação do Devin
Localização dos arquivos
Arquivos criados por você
Estes são os arquivos de entrada machine-wide. Cada um tem um caminho padrão e uma variável de ambiente que o substitui; essa variável precisa estar definida no ambiente em que o agente é iniciado (consulte Variáveis de ambiente da chave de API para saber como fazer isso no Desktop).
Os valores padrão são os mesmos no macOS e no Linux. No Windows, a licença, o arquivo de modelos e o arquivo de autenticação ficam, por padrão, em
C:\ProgramData\Devin\ (license.devin-onprem-license, models.json, auth.json), o arquivo de políticas machine-wide fica em C:\ProgramData\Devin\system.json e as variáveis de override são as mesmas; restrinja o acesso à pasta antes de colocar arquivos nela. A CLI apenas lê esses arquivos e nunca grava neles, então você pode gerenciá-los com suas ferramentas de gerenciamento de configuração e deixá-los como somente leitura.
Estado por usuário gravado pela CLI
A CLI segue a estrutura de diretórios base XDG tanto no macOS quanto no Linux (ela não usa~/Library para armazenar o próprio estado). As variáveis XDG_CONFIG_HOME e XDG_DATA_HOME são respeitadas quando definidas.
cli-federal é o subdiretório do produto usado pelo build air-gapped; ele mantém esse estado separado de qualquer instalação da Devin CLI padrão na mesma máquina, que usa cli.
No Windows, a CLI não lê as variáveis XDG_*. Ela mantém os mesmos arquivos em %APPDATA%\devin\ e o cache em %LOCALAPPDATA%\devin\:
Estado específico do Desktop
O aplicativo Desktop fica isolado de qualquer outra instalação do Devin Desktop ou do Windsurf na mesma máquina:
O link simbólico só é criado na inicialização do Desktop se não existir nada em
~/.devin-airgap-config/devin/config.json. Se já houver um arquivo comum nesse local, o Desktop não mexe nele e o agente incluído passa a usar esse arquivo em vez do compartilhado; o canal de saída Devin ACP registra uma linha WARNING: … is a regular file, not a symlink. Para restaurar o link, exclua o arquivo e reinicie o Desktop.
No Windows, não há link simbólico. O agente incluído no Desktop e a CLI compartilham diretamente o %APPDATA%\devin\config.json, e o Desktop não carrega o %APPDATA%\devin\mcp_config.json do usuário. Os dados de usuário do Desktop ficam em %APPDATA%\Devin - Airgap\.
Somente ~/.devin-airgap-config/ e ~/.devin-airgap/ podem ser excluídos com segurança para uma reinstalação do zero. Os diretórios ~/.config/devin/ e ~/.local/share/devin/ também pertencem à CLI independente.
Registro de auditoria
A CLI air-gapped grava um registro de auditoria local, estruturado e append-only (somente acréscimo). Ele fica sempre ativo (não há controle para desativá-lo), não existe em nenhum outro build do Devin e é gravado na estação de trabalho para sua própria revisão e para ingestão no SIEM.Local e rotação
Se precisar de retenção ilimitada, envie os arquivos rotacionados para o seu SIEM antes que sejam descartados. Como a CLI apenas acrescenta linhas e nunca reescreve as existentes, basta um coletor padrão de leitura contínua de arquivos; consulte Encaminhe o registro de auditoria para o seu SIEM.
Garantias de ocultação de dados
Os eventos contêm apenas caminhos e metadados. O log nunca inclui prompts, respostas do modelo, código, conteúdo de arquivos, valores de segredos, chaves de API nem linhas de comando de shell completas: para ferramentas de shell, apenas o nome do programa (o primeiro token) é registrado.Envelope (versão 1 do schema)
Toda linha contém este envelope; os campos específicos de cada evento ficam no mesmo nível que ele.
Configure seu parser para ignorar campos desconhecidos e valores de
event desconhecidos: novos campos e tipos de evento podem ser adicionados sem que o schema_version seja incrementado.
Tipos de evento
session_start
Emitido quando uma sessão de agente é iniciada (sessão raiz nova ou retomada).
session_end
Emitido quando a sessão termina ou o agente é encerrado.
session_start é pareado com exatamente um session_end para o mesmo session_id. A CLI executa o agente em um processo filho, que ela encerra durante a finalização; por isso, o processo pai registra o session_end da sessão filha (motivo other) quando a sessão termina. Uma sessão encerrada por SIGKILL ou por queda de energia não consegue gravar um evento final; trate um session_start sem um session_end correspondente como um encerramento anormal.
tool_call
Emitido após cada execução de ferramenta pelo agente.
file_read e file_write
Emitidos junto com tool_call, uma vez para cada caminho no escopo de permissão resolvido da ferramenta. Eles descrevem o acesso para o qual a ferramenta tinha escopo definido, e não operações de E/S verificadas: uma ferramenta aprovada com escopo de leitura sobre vários caminhos emite um file_read para cada caminho, mesmo que tenha acessado apenas alguns deles, e os eventos são emitidos independentemente de a chamada de ferramenta ter sido bem-sucedida ou não.
model_call
Emitido após cada requisição de inferência a um endpoint de modelo definido no seu arquivo de modelos.
Os campos de tokens são omitidos quando o endpoint não informa o uso.
auth
Objeto actor
A atribuição de identidade é composta pelo usuário do sistema operacional, pela identidade Git local e (quando o SSO está configurado) pela identidade do token de ID validado. Campos indisponíveis são omitidos.
Os campos de SSO aparecem em todo evento
auth que tenha um token validado disponível (sso_login, sso_refresh, sso_logout, sso_login_denied), em sso_revalidation_failed para o login validado pelo processo (ou, se nenhum tiver sido validado, para o login que ainda está no cache de tokens) e em session_start e identity_resolved para o login que o processo em execução validou na inicialização. tool_call, file_read, file_write e model_call não incluem actor; para atribuí-los, use o session_id para associá-los ao respectivo session_start.
sso_groups grava o pertencimento a grupos do IdP de cada usuário na máquina local. O diretório e os arquivos de auditoria só podem ser acessados pelo proprietário; inclua-os na revisão de tratamento de dados se os nomes de grupos forem confidenciais no seu ambiente.Encaminhe o registro de auditoria para o seu SIEM
O Devin não envia registros de auditoria para nenhum lugar. Para agregar o uso de várias estações de trabalho, aponte o agente de coleta de logs que o seu SIEM já utiliza (por exemplo, um Splunk universal forwarder ou o Elastic Agent) para o diretório de auditoria em cada estação de trabalho. Nenhuma configuração do Devin é necessária. Configure a entrada de arquivos do agente com os seguintes parâmetros:
A estação de trabalho de cada usuário mantém o arquivo ativo e no máximo 10 arquivos rotacionados de 10 MiB cada, cerca de 110 MiB no total. Registros além desse limite são excluídos; portanto, uma estação de trabalho que gere mais do que esse volume entre uma coleta e outra perde os registros mais antigos.
Para confirmar que a coleta está funcionando, inicie e encerre uma sessão do Devin em uma estação de trabalho e, em seguida, pesquise no seu SIEM um registro
session_start e um registro session_end com o mesmo session_id.
Exemplo: Splunk universal forwarder
Implante estes dois arquivos em um app em cada forwarder (por exemplo,$SPLUNK_HOME/etc/apps/devin_audit/local/). Use apenas a stanza monitor correspondente ao sistema operacional da estação de trabalho e substitua devin pelo índice que você deseja usar.
inputs.conf
props.conf
props.conf precisa estar no forwarder, e não apenas nos indexers, porque INDEXED_EXTRACTIONS é aplicado onde o arquivo é lido. Não defina crcSalt: assim, o forwarder reconhece um arquivo rotacionado pelo conteúdo e não o lê novamente com o novo nome. Todos os diretórios no caminho com curinga precisam ter permissão de leitura para a conta com a qual o forwarder é executado; um forwarder instalado como uma conta de serviço não root não consegue ler os diretórios de auditoria acessíveis apenas ao proprietário.
Os campos chegam como campos indexados com seus nomes JSON, de modo que actor.sso_user, model e input_tokens podem ser pesquisados diretamente:
Exemplo: Elastic (Filebeat ou Elastic Agent)
Adicione esta entradafilestream ao filebeat.yml. Mantenha apenas o caminho correspondente ao sistema operacional da estação de trabalho.
filebeat.yml
ndjson coloca cada registro sob o prefixo devin. (devin.event, devin.session_id, devin.actor.sso_user). Não defina target: "": o campo event do registro é uma string, o que entra em conflito com o objeto event do Elastic Common Schema e faz o Elasticsearch rejeitar os documentos. O processador timestamp copia ts para @timestamp; a Elastic classifica esse processador como beta, então, se preferir, remova-o e defina @timestamp a partir de devin.ts em um pipeline de ingestão. O id deve ser único entre seus inputs filestream. A identidade de arquivo padrão do Filebeat é uma impressão digital (fingerprint) do início do arquivo, que continua identificando o arquivo após a renomeação feita pela rotação, portanto não é necessário configurar nada para a rotação. O comprimento da impressão digital foi reduzido do padrão de 1024 bytes para 64 porque as versões 9.0 a 9.4 do Filebeat ignoram um arquivo até que ele atinja pelo menos esse tamanho, o que faria com que uma estação de trabalho com poucos registros fosse ignorada. Os primeiros 64 bytes de um arquivo de auditoria contêm o ts e o pid do primeiro registro, o que garante impressões digitais distintas. Alterar o comprimento posteriormente faz com que o Filebeat leia todos os arquivos novamente.
Com o Elastic Agent, adicione a integração Custom Logs (Filestream) à política do agente, informe os mesmos caminhos e coloque os blocos parsers e processors acima no campo de configuração personalizada da integração.
A Cognition não testou estes exemplos em um deployment do Splunk ou do Elastic. Valide-os no seu ambiente e consulte a documentação do fornecedor referente à versão instalada antes de implantá-los nas estações de trabalho.
Somente os registros
session_start e auth identificam o usuário. Para atribuir registros tool_call, file_read, file_write e model_call a um usuário, associe-os ao registro session_start com o mesmo session_id.
Relatório de diagnósticos
devin diagnostics gera um relatório em texto simples, com dados sensíveis ocultados, que você pode revisar antes de enviá-lo ao suporte da Cognition. O relatório contém apenas versões, a estrutura da configuração (se cada arquivo existe e pode ser interpretado), nomes de modelos, se cada variável de chave de API está definida e estatísticas do registro de auditoria. Ele nunca inclui prompts, código, conteúdo de arquivos, valores de segredos, URLs de endpoints ou valores de variáveis de ambiente.
--output <path> para definir o nome do arquivo. O relatório é gravado com permissão restrita ao proprietário (0600). Consulte Solução de problemas para saber o que incluir em uma solicitação de suporte.