Segurança e controles de LLM

Os modelos de IA podem se comportar de forma inesperada. Esta documentação explica como controlar o que os agentes podem fazer, configurar limites de segurança e orientar o comportamento dos LLMs para alcançar os resultados desejados.

Entendendo o comportamento dos modelos

LLMs geram texto com base em distribuições de probabilidade, não recuperando fatos de um banco de dados nem executando lógica determinística. Podem produzir saídas diferentes para a mesma entrada, inventar fatos ou código que parecem plausíveis, mas estão errados, e ser influenciados por prompts cuidadosamente elaborados (injeção de prompt).

Não é possível confiar que os LLMs sempre tomarão decisões seguras. Em vez disso, combine duas abordagens: controles de segurança que impõem limites rígidos ao que os agentes podem fazer e mecanismos de direcionamento que orientam o comportamento dos LLMs para melhores resultados.

Para entender melhor como os LLMs funcionam, consulte Como os modelos de IA funcionar.

Duas abordagens de segurança

O Cherri Code oferece duas abordagens complementares para gerenciar o comportamento dos agentes de IA:

Controles de segurança (aplicação determinística): Limites rígidos que bloqueiam operações perigosas, independentemente do que o LLM sugira. Eles incluem restrições de comandos no terminal, hooks de aplicação que rejeitam operações, fluxos de aprovação e sandboxing. Os controles de segurança são sua principal defesa contra ações prejudiciais de agentes.

Direcionamento do LLM (orientação não determinística): Mecanismos que orientam o LLM a adotar um comportamento melhor, moldando seu contexto e as ações disponíveis. Eles incluem Regras que adicionam instruções aos prompts, Comandos que fornecem fluxos de trabalho reutilizáveis e integrações que ampliam o conhecimento do agente. O direcionamento melhora a qualidade do agente, mas não garante a prevenção de ações prejudiciais.

Use as duas abordagens em conjunto. Os controles de segurança fornecem uma rede de proteção. O direcionamento reduz a frequência com que os agentes tentam realizar ações problemáticas.

Controles de segurança

Esses controles determinísticos impõem limites rígidos ao que os agentes podem fazer, independentemente do que o LLM sugira.

Restrições de comandos de terminal

Por padrão, o Cherri Code exige sua aprovação antes de executar qualquer comando de terminal. Isso protege contra comandos destrutivos (que excluem arquivos ou removem bancos de dados), comandos que expõem dados sensíveis e comandos com efeitos colaterais indesejados.

Quando um agente quer executar um comando, você vê um prompt com o comando completo. Você pode aprová-lo e executá-lo, negá-lo ou modificá-lo antes de executá-lo.

Riscos da aprovação automática

Você pode ativar a aprovação automática para comandos de terminal, mas esteja ciente dos riscos. Os agentes podem executar comandos destrutivos sem que você saiba, os comandos são executados antes que você possa revisá-los, e bugs ou injeções de prompt podem causar operações não intencionais.

Configuração do modo de execução

Equipes corporativas podem configurar políticas de modo de execução no dashboard da equipe. No Cherri Code 3.6 e versões posteriores, os usuários finais podem escolher entre os modos Auto-review (o padrão), Allowlist e Run Everything. O Auto-review executa chamadas incluídas na lista de permissão, isola comandos de shell em sandbox quando possível e encaminha o restante para um classificador de LLM, que permite ou bloqueia com base na segurança e em quanto a chamada corresponde à intenção do usuário. Você pode criar uma lista de permissão de comandos que não exigem aprovação, como npm install, pip install, cargo build ou make test.

A lista de permissão é uma medida de melhor esforço, não uma fronteira de segurança. Agentes determinados ou injeções de prompt podem contorná-la. Sempre combine listas de permissão com outros controles de segurança, como hooks.

Consulte Modos de execução e Segurança dos agentes para mais detalhes.

Hooks de enforcement

Os hooks permitem executar lógica personalizada em pontos-chave do loop do agente.

• Antes do envio do prompt: Analise os prompts em busca de dados sensíveis antes de enviá-los aos LLMs. Bloqueie envios que contenham chaves de API ou credenciais, informações de identificação pessoal (PII) ou informações proprietárias.
• Antes da leitura de arquivos: Analise os arquivos antes que os agentes os leiam. Oculte informações ou bloqueie o acesso a arquivos de configuração com segredos, PII em bancos de dados ou logs, ou algoritmos proprietários.
• Após a geração de código: Analise o código gerado antes de gravá-lo no disco. Verifique se há vulnerabilidades de segurança (injeção de SQL, XSS), código licenciado que possa causar problemas de propriedade intelectual ou chaves de API e credenciais no código.
• Antes da execução no terminal: Bloqueie comandos perigosos ou encaminhe-os para fluxos de aprovação. Por exemplo, bloqueie todos os comandos git push, exija aprovação para qualquer comando sudo ou bloqueie instruções DROP em bancos de dados.

Exemplo: Bloqueio de comandos do git

Este hook intercepta comandos de shell e bloqueia o uso direto do git, orientando os usuários a usar a GitHub CLI:

#!/bin/bashinput=$(cat)command=$(echo "$input" | jq -r '.command')if [[ "$command" =~ git[[:space:]] ]]; then    cat << EOF{  "permission": "deny",  "userMessage": "Git command blocked. Please use gh tool instead.",  "agentMessage": "Use 'gh' commands instead of raw git."}EOFfi

Exemplo: Ocultação de segredos

Este hook analisa o conteúdo dos arquivos em busca de chaves de API do GitHub e bloqueia o acesso caso as encontre:

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')if echo "$content" | grep -qE 'gh[ps]_[A-Za-z0-9]{36}'; then    cat << EOF{  "permission": "deny"}EOF    exit 3fi

Consulte a documentação sobre hooks para mais detalhes e exemplos.

Proteção de arquivos sensíveis

Nem todos os arquivos dos seus repositórios devem ficar acessíveis à IA. Arquivos de configuração, segredos e dados sensíveis precisam ser protegidos.

.cursorignore

O arquivo .cursorignore funciona como o .gitignore, mas controla o que o Cherri Code pode acessar. Arquivos que correspondem aos padrões em .cursorignore são excluídos de:

• Leitura de arquivos pelo agente
• Seleção de contexto

.cursorignore não é uma fronteira de segurança. É uma funcionalidade prática para excluir arquivos do processamento por IA, mas:

• Os usuários podem ler arquivos ignorados manualmente
• Os agentes podem encontrar maneiras de acessar conteúdo ignorado
• Comandos de terminal e ferramentas MCP ainda podem ler arquivos ignorados

Para garantir segurança de fato, use permissões do sistema de arquivos ou criptografe dados sensíveis.

Consulte Ignore Files para ver a sintaxe detalhada.

Proteção do diretório .cursor

O diretório .cursor nos repositórios contém configurações, regras e arquivos de cache específicos do projeto. Equipes corporativas podem impedir que agentes modifiquem esse diretório.

Quando habilitada, essa proteção impede que os agentes:

• Modifiquem arquivos em .cursor/
• Excluam o diretório .cursor/
• Alterem regras do Cherri Code ou arquivos de configuração

Os usuários ainda podem editar esses arquivos manualmente, mas os agentes precisam de aprovação.

Configure no dashboard da equipe, em "Proteção do diretório .cursor" (somente para Enterprise).

Controles de origem do navegador

Equipes corporativas podem restringir os sites que os agentes podem acessar ao usar a ferramenta do navegador. Defina uma lista de permissão de domínios aprovados — os agentes que tentarem visitar outras origens serão bloqueados.

Configure no dashboard da equipe, em "Controles do navegador" (somente para Enterprise).

Integração com ferramentas de DLP

Muitas empresas já usam ferramentas de Prevenção contra Perda de Dados (DLP) para detectar dados sensíveis. Você pode integrar o Cherri Code às suas ferramentas de DLP de três maneiras.

Agentes DLP de endpoint

A maioria dos softwares de DLP para endpoints consegue inspecionar o tráfego de rede do Cherri Code. Configure seu DLP para monitorar o tráfego nos domínios *.cursor.sh, verificar padrões sensíveis em solicitações de saída e bloquear ou alertar sobre violações de política.

O DLP de rede pode afetar o desempenho. Consulte Configuração de rede para obter informações sobre proxies.

DLP com hooks

Use a funcionalidade de hooks do Cherri Code para implementar lógica de DLP personalizada:

Antes do envio de prompts: Verifique se há padrões sensíveis nos prompts antes de enviá-los aos LLMs:

#!/bin/bashinput=$(cat)prompt=$(echo "$input" | jq -r '.prompt')# Verificar chaves de APIif echo "$prompt" | grep -qE 'api[_-]?key.*[A-Za-z0-9]{32}'; then    cat << EOF{  "continue": false,  "userMessage": "Prompt contains what looks like an API key. Remove it and try again."}EOF    exit 1fi# Permitir se nenhum dado sensível for encontradocat << EOF{  "continue": true}EOF

Após a geração de código: Verifique o código gerado antes de gravá-lo no disco:

#!/bin/bashinput=$(cat)file_path=$(echo "$input" | jq -r '.file_path')edits=$(echo "$input" | jq -r '.edits[].new_string')# Verifique se há credenciais codificadas diretamenteif echo "$edits" | grep -qE 'password.*=.*["\047][^"\047]+["\047]'; then    # Envie para a API de DLP da sua empresa para análise    curl -X POST "https://dlp.yourcompany.com/scan" \      -H "Content-Type: application/json" \      -d "{\"content\":\"$edits\",\"file\":\"$file_path\"}"        # Verifique a resposta da API e tome as medidas necessáriasfi

Integração com DLP de terceiros

Chame a API do seu fornecedor de DLP atual usando hooks:

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')# Envia para a API de DLPresponse=$(curl -s -X POST "https://dlp-api.company.com/analyze" \  -H "Authorization: Bearer $DLP_API_TOKEN" \  -H "Content-Type: application/json" \  -d "{\"text\":\"$content\"}")# Processa a respostais_allowed=$(echo "$response" | jq -r '.allowed')if [ "$is_allowed" = "true" ]; then    cat << EOF{  "permission": "allow"}EOFelse    violation=$(echo "$response" | jq -r '.violation_type')    cat << EOF{  "permission": "deny",  "userMessage": "Content blocked by DLP policy: $violation"}EOFfi

Essa abordagem permite gerenciar centralmente as políticas de DLP em todas as ferramentas de desenvolvimento.

Fluxos de aprovação

Você pode configurar o Cherri Code para solicitar aprovação para cada ação do agente. Os usuários podem configurar o agente para sempre pedir aprovação antes de ler ou editar arquivos, executar comandos de terminal ou fazer solicitações de rede.

No entanto, essa abordagem deixa a experiência de desenvolvimento significativamente mais lenta. Os agentes precisam realizar várias ações para concluir tarefas, e exigir aprovação para cada uma delas torna o fluxo de trabalho tedioso. Por isso, a maioria das equipes opta por usar hooks para bloquear automaticamente operações perigosas.

Segurança dos provedores de modelos

Todos os provedores de modelos (OpenAI, Anthropic, Google, SpaceXAI) implementam sistemas de segurança que filtram conteúdo nocivo. Esses sistemas rejeitam prompts que solicitam informações nocivas, recusam-se a gerar código perigoso e filtram saídas por segurança.

O Cherri Code trabalha com os provedores para garantir que os modelos atendam aos padrões de segurança antes de serem disponibilizados aos usuários. Os provedores avaliam continuamente os modelos em busca de problemas de segurança. No entanto, esses sistemas não são barreiras de segurança. Eles podem ser contornados ou enganados. Sempre implemente seus próprios controles por meio de hook e políticas de acesso.

Considerações sobre sandboxing

Por padrão, os agentes do Cherri Code são executados na sua máquina local. Eles podem ler os arquivos que você pode ler, gravar nos arquivos em que você pode gravar, executar os comandos que você pode executar e acessar os recursos de rede que você pode acessar.

Não há uma fronteira de segurança entre os agentes e sua conta de usuário. Se sua conta puder excluir arquivos, os agentes também poderão excluí-los (com aprovação por padrão).

Opções de sandboxing

Se precisar de maior isolamento, execute o Cherri Code em uma VM separada usando agentes em nuvem, use permissões do sistema de arquivos para limitar o que o processo do Cherri Code pode acessar ou execute o Cherri Code em uma máquina de desenvolvimento dedicada com acesso limitado a sistemas de produção.

Para a maioria das empresas, os requisitos de aprovação e os hooks integrados oferecem controle suficiente.

Permissões do sistema de arquivos

Como medida adicional de proteção, use as permissões do sistema de arquivos para proteger arquivos sensíveis:

Restrinja o acesso a arquivos confidenciais:

# Permita que apenas usuários específicos leiam os segredoschmod 600 .envchown app-user:app-user .env# Ou use diretórios separados com acesso restritochmod 700 /etc/app/secrets

Repositórios confidenciais separados: Mantenha códigos altamente confidenciais em repositórios separados com acesso restrito. Não clone esses repositórios em máquinas que executam o Cherri Code.

Sistemas de arquivos criptografados: Para dados muito confidenciais, use sistemas de arquivos criptografados que exijam montagem explícita. Não monte esses sistemas de arquivos em diretórios aos quais o Cherri Code tenha acesso.

Direcionamento do LLM

Os controles de segurança bloqueiam ações prejudiciais depois que o LLM as sugere. Os mecanismos de direcionamento orientam o LLM a fazer sugestões melhores desde o início. Eles são não determinísticos. Melhoram os resultados, mas não garantem a prevenção.

Regras

As regras adicionam instruções à janela de contexto do LLM antes de cada solicitação. Use regras para estabelecer padrões de código, aplicar padrões arquiteturais, definir requisitos de segurança ou convenções específicas do projeto.

As regras funcionam em três escopos:

Regras do Usuário: Aplicam-se a todos os projetos de um usuário específico. Use-as para definir preferências pessoais, como estilo de código ou bibliotecas preferidas.

Regras do projeto: Aplicam-se a todas as pessoas que trabalham em um projeto. Use-as para definir padrões específicos do projeto, como convenções de nomenclatura ou uso de frameworks.

Regras da equipe: Aplicam-se a todos os projetos da sua organização. Use-as para definir padrões para toda a empresa, como requisitos de segurança ou regras de compliance.

O LLM considera todas as regras aplicáveis ao gerar respostas. Ele tentará segui-las, mas as regras são sugestões, não garantias. Combine regras com hooks de enforcement para requisitos que precisam ser seguidos.

Consulte Regras para ver configurações e exemplos.

Comandos e fluxos de trabalho

Os comandos reúnem prompts reutilizáveis que os agentes podem invocar com comandos slash, como /test ou /deploy. Eles ajudam a padronizar fluxos de trabalho comuns em toda a equipe.

Fluxos de trabalho: Crie processos de várias etapas que orientam os agentes em tarefas complexas. Por exemplo, um comando /security-review pode instruir o agente a verificar vulnerabilidades de injeção de SQL, checar segredos expostos, validar a sanitização de entradas e gerar um relatório de segurança.

Bibliotecas de prompts: Crie uma coleção de prompts testados para tarefas comuns. Isso reduz a variação no comportamento dos agentes e registra o conhecimento institucional.

Os comandos podem ter escopo de equipe, projeto ou usuário. Admins da equipe podem criar comandos para toda a organização, disponíveis para todos os desenvolvedores.

Consulte Comandos para ver configurações e exemplos.

Enriquecimento de contexto com MCPs

Servidores do Model Context Protocol (MCP) permitem que agentes acessem fontes de dados externas. Use MCPs para obter documentação da empresa, consultar APIs internas, acessar bases de conhecimento ou integrar ferramentas de desenvolvimento.

Os MCPs enriquecem o contexto do agente com informações às quais ele não teria acesso de outra forma. Por exemplo, um MCP pode fornecer acesso às especificações da sua API, permitindo que os agentes gerem código que chama corretamente seus serviços internos.

Os MCPs são restritos a equipes ou usuários. Ao contrário dos hooks, os MCPs não aplicam políticas — eles fornecem informações que ajudam os agentes a tomar melhores decisões.

Consulte Integração com MCP para ver configurações e exemplos.