A segurança do DeepSeek V4 Pro depende do ambiente do agente — não só do modelo

Organizações que implantam agentes baseados no DeepSeek V4 Pro devem avaliar uma configuração completa de modelo–harness–tarefa–ambiente, e não o modelo de forma isolada. A disponibilidade por diferentes interfaces pode mostrar que um runtime consegue se comunicar com o modelo, mas não prova que prompts, ferramentas, permissões, memória, tentativas automáticas ou efeitos colaterais funcionarão da mesma maneira em todos eles.

A regra operacional é simples: aprove uma configuração específica e fixada somente depois que ela passar por sua própria avaliação de segurança.

Por que o harness muda o agente efetivo

Um agente é mais do que o modelo que está por trás dele. O harness — a camada que coordena instruções, ferramentas, sessões e execução — determina como o modelo recebe comandos, escolhe ferramentas, acessa dados, lida com falhas e interage com sistemas externos.

Entre as diferenças que podem alterar materialmente o risco estão:

• prompts de sistema e adaptadores;
• definições e implementações das ferramentas;
• escopos de permissão e etapas de aprovação;
• raízes do sistema de arquivos e acesso à rede;
• fontes de credenciais e identidade usada;
• comportamento de subprocessos e código gerado;
• lógica de novas tentativas, tempo limite e concorrência;
• estado da sessão, resumos, caches e memória persistente.

Por isso, o mesmo backend do DeepSeek V4 Pro pode apresentar perfis de risco diferentes quando é conectado a harnesses ou ambientes de execução distintos. Um esquema de API compatível é uma propriedade de integração — não uma certificação de segurança.

O que os resultados do AgentS4D mostram — e o que não mostram

O AgentS4D avaliou configurações completas de runtime, em vez de respostas isoladas do modelo. O benchmark usou 328 casos com riscos injetados em quatro harnesses e cinco backends de modelos, totalizando 6.560 execuções em sandbox. Foram registradas 4.461 execuções inseguras, ou 68,0%, e 4.344 execuções, ou 66,22%, que eram ao mesmo tempo inseguras e consideradas concluídas. 13

A principal conclusão é que concluir uma tarefa com sucesso pode coexistir com uma execução insegura. Um agente pode entregar o artefato solicitado e, durante o processo, fazer uma alteração proibida, tratar dados sensíveis de forma inadequada, contornar um controle previsto ou gerar outro efeito colateral perigoso.

Esses números não devem ser apresentados como a taxa de incidentes do DeepSeek V4 Pro em produção. A avaliação usou casos deliberadamente projetados para injetar riscos, em um sandbox controlado, e agregou resultados de várias combinações entre modelo e harness. O conjunto de tarefas, os controles, a exposição a conteúdo adversarial, os ativos envolvidos e as definições de dano serão diferentes em ambientes reais. O benchmark mostra que a segurança do runtime precisa ser medida diretamente — não prevê o que acontecerá em toda implantação. 135

Reduza a consequência máxima das ações do agente

Os controles devem limitar o impacto dos erros mesmo quando o modelo ou uma ferramenta se comporta de maneira inesperada.

Use identidades dedicadas e com menor privilégio

Crie identidades separadas para agentes, ambientes e clientes (tenants). Evite credenciais de funcionários disponíveis no ambiente, acesso de administrador à produção e segredos amplamente reutilizáveis. Cada identidade deve ter somente os recursos e operações necessários para um trabalho específico.

Restrinja sistemas de arquivos e redes

• Monte apenas uma raiz de workspace dedicada.
• Torne caminhos não relacionados inacessíveis, em vez de apenas ocultá-los.
• Crie listas de permissão para destinos, métodos, portas e, quando pertinente, volume de saída de dados.
• Separe capacidades de leitura, rascunho, gravação em homologação e gravação em produção.
• Mantenha segredos em um broker ou sistema de tokens de curta duração.
• Nunca coloque credenciais de longa duração em prompts, arquivos do workspace, variáveis de ambiente ou saídas de ferramentas.

Ações de alto impacto — como apagar dados, publicar conteúdo, realizar pagamentos, alterar acessos, fazer deploy ou enviar comunicações externas — devem passar por uma verificação de política na camada de execução ou exigir uma aprovação explícita.

Revise toda a cadeia de execução

Ferramentas oficiais são apenas uma parte da superfície de ataque. Processos filhos, comandos de shell, código gerado, instalação de pacotes, servidores remotos de ferramentas, plugins e código de skills também podem produzir efeitos colaterais.

A mesma política deve valer para todos esses caminhos. Em especial, impeça que o shell ou o código gerado contorne controles de sistema de arquivos, rede, autorização, registros de auditoria ou aprovação.

Faça as ferramentas obedecerem a regras fora do modelo

Uma chamada de ferramenta gerada pelo modelo é uma solicitação não confiável. Quem deve aplicar as regras de autorização e segurança é o servidor da ferramenta — não o modelo.

Use esquemas restritos com controles como:

• valores enumerados e limites de tamanho;
• normalização de caminhos e identificadores explícitos de recursos;
• listas de destinos permitidos;
• limites de paginação e de tamanho dos resultados;
• validação de argumentos fora do modelo;
• autorização no servidor para o chamador, cliente, alvo e operação específicos.

Separe ferramentas de planejamento ou pré-visualização das ferramentas que produzem efeitos. Para operações destrutivas ou difíceis de reverter:

• exija pré-visualização e confirmação ou um token de aprovação;
• prefira exclusão lógica, quarentena ou fluxos reversíveis;
• exija chaves de idempotência;
• defina o que ocorre quando a mesma solicitação é repetida;
• retorne comprovantes persistentes para que novas tentativas não repitam o efeito.

Esses controles são importantes porque uma chamada JSON aparentemente válida ainda pode conter um alvo não autorizado, um caminho perigoso, um escopo excessivo ou uma operação que deveria passar por revisão humana.

Defina o comportamento de estado e memória antes da implantação

O estado pode transportar riscos entre turnos, tarefas, usuários e ambientes. As organizações devem documentar e aplicar regras de ciclo de vida para mensagens, arquivos enviados, arquivos do workspace, resumos, resultados de ferramentas, caches e memória persistente.

No mínimo, especifique:

• Isolamento: separe o estado por usuário, cliente, tarefa e ambiente; não permita compartilhamento implícito entre sessões.
• Retenção: defina tempo de vida, criptografia, controle de acesso e regras de exclusão.
• Redefinição: ofereça uma forma documentada de limpar contexto, memória, estado do workspace, credenciais e caches entre execuções.
• Novas tentativas e tempos limite: imponha contagens e orçamentos limitados; as repetições devem preservar a idempotência e não ampliar privilégios silenciosamente.
• Concorrência: defina bloqueios e tratamento de conflitos para arquivos compartilhados, aprovações e operações externas.

Trate o comportamento de redefinição do estado como parte da fronteira de segurança. Se instruções antigas, credenciais ou resultados de ferramentas puderem reaparecer inesperadamente em uma nova tarefa, uma atualização do modelo ou uma mudança no prompt poderá alterar o risco de formas que testes baseados apenas nas respostas não detectariam.

Considere todo vetor de risco como entrada não confiável

Uma injeção de prompt não precisa chegar na mensagem direta do usuário. Instruções potencialmente perigosas podem estar embutidas em:

• documentos enviados e arquivos de repositórios;
• páginas recuperadas da internet;
• skills e plugins externos;
• respostas de serviços de ferramentas;
• memória persistente;
• resumos e contexto armazenado em cache;
• textos fornecidos pelo usuário.

Esse material deve ser analisado, rotulado e citado como dado. Ele não pode alterar a autoridade do agente, a política aplicada, a escolha de ferramentas, o uso de credenciais ou as exigências de aprovação. O runtime deve impor essa separação, em vez de depender exclusivamente da capacidade do modelo de reconhecer instruções maliciosas.

Checklist de lançamento específico do harness

Antes de aprovar uma implantação, congele e registre a configuração exata:

1. Modelo e roteamento: identificador e versão do modelo, rota do provedor, configurações de inferência ou nível de esforço e adaptadores de compatibilidade.
2. Comportamento do harness: versão do harness, prompt de sistema, lógica de sessão, regras de novas tentativas e tempo limite, política de subprocessos e implementação da memória.
3. Ferramentas e políticas: definições e versões das ferramentas, versões das políticas, limites de aprovação, lógica de autorização e fronteiras de confiança dos servidores de ferramentas.
4. Permissões: identidades, escopos, raízes do sistema de arquivos, destinos de rede, fontes de credenciais e caminhos de gravação em produção.
5. Semântica do estado: isolamento, retenção, redefinição, comportamento de cache, concorrência e fronteiras entre sessões.
6. Cobertura adversarial: injeção de prompt por todos os vetores de risco, tentativas de agente confuso (confused deputy), exposição de credenciais, travessia de caminhos, SSRF ou abuso de saída de rede, respostas maliciosas de ferramentas, duplicação por novas tentativas, envenenamento de memória e contorno de aprovações.
7. Evidências: versões de prompts e políticas, chamadas e resultados de ferramentas, aprovações, decisões de política, diferenças no workspace, requisições de saída, identidade usada, artefatos finais, resultado de conclusão e resultado de segurança sob um ID de execução estável.

Avalie conclusão e segurança separadamente. Um artefato final correto não deve compensar um efeito colateral inseguro — essa é a principal lição dos resultados do AgentS4D. 12

Repita os testes sempre que a configuração mudar

O alvo aprovado é a configuração fixada, não um rótulo permanente como “agente DeepSeek V4 Pro”. Repita a bateria específica da configuração após qualquer alteração relevante em:

• modelo ou rota do provedor;
• configurações de inferência ou nível de esforço;
• prompt de sistema ou adaptador;
• lógica do harness ou da sessão;
• ferramentas ou servidores remotos de ferramentas;
• políticas de permissão e aprovação;
• roteamento de credenciais;
• comportamento de memória, novas tentativas, tempo limite ou concorrência;
• limites de rede ou sistema de arquivos.

Essa abordagem transforma a segurança do runtime de uma suposição ampla sobre a qualidade do modelo em uma decisão de lançamento mensurável, vinculada ao ambiente exato capaz de produzir efeitos no mundo real.