Diminuir os riscos de injeção indireta de comando do MCP do Google Cloud

Visualizar

Este produto está sujeito aos "Termos da Pré-GA" nos Termos Gerais de Serviço dos Termos Específicos de Serviço e aos Termos Adicionais para Produtos Pré-lançamento de IA Generativa. Os produtos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições das fases de lançamento.

Os agentes de programação geralmente são implantados localmente em uma estação de trabalho do usuário, aproveitando a autoridade delegada pelo usuário controlador para acessar dados. Em geral, os agentes de programação são executados com todos os privilégios do usuário, mas, ao contrário dos humanos, são suscetíveis à injeção de comandos que ditam suas ações. Isso pode representar riscos para sua infraestrutura e dados que você precisa considerar.

Os agentes podem interpretar dados erroneamente como instruções, às vezes chamadas de injeção indireta de comando. Por exemplo, um agente malicioso pode criar alguns comandos maliciosos, compartilhar com uma vítima diretamente (por exemplo, em um e-mail ou na agenda) ou indiretamente (por exemplo, incluindo-os no Cloud Storage ou no BigQuery) e esperar que o agente execute esses comandos maliciosos.

Para reduzir o risco, recomendamos que você considere as seguintes restrições adicionais.

1. Execute os agentes em um ambiente restrito sempre que possível. Um exemplo canônico é fazer com que os usuários abram agentes apenas nas Cloud Workstations, desativando o acesso à Internet e sem privilégios de root. Também recomendamos configurar proteções de VPC-SC no Cloud Workstations.

2. Cabeçalho de restrição da organização: como alternativa, as organizações com proxies de segurança de rede no limite da rede corporativa podem ativar o cabeçalho de restrição da organização. Quando implantado, isso restringe o conjunto de recursos acessíveis da rede corporativa a um conjunto específico deGoogle Cloud organizações (como a organização principal da empresa), impedindo que agentes (e humanos) acessem recursos fora do locatário corporativo do Google Cloud. Se a organização já usar um proxy de saída, ele poderá oferecer suporte a esse recurso sem precisar de configuração.

3. Limites de acesso principal (PABs): os PABs permitem limitar o conjunto de recursos que um determinado conjunto de identidades pode acessar. Para agentes de programação, eles podem ser executados como a própria identidade (por exemplo, uma conta de serviço ou a identidade do agente recém-disponibilizada, compatível com o Vertex AI Agent Engine) ou usando a autoridade delegada do usuário. Os PABs podem ser ativados para restringir o acesso apenas aos recursos da organização em ambos os casos, mas aplicar o limite à identidade humana também limita o acesso da pessoa.

   Observação: os humanos estão sujeitos aos mesmos tipos de riscos de phishing que os agentes por meio de conjuntos de dados públicos, mas outros controles de segurança na empresa podem ser mais adequados para gerenciar esses riscos do que para agentes.

4. VPC Service Controls: organizações que incluem a rede corporativa em um perímetro do VPC Service Controls já estão protegidas contra esses riscos quando eles se originam diretamente de fora do perímetro da VPC. As organizações que se preocupam com a exfiltração de dados pelo Google Cloud, inclusive por agentes, podem considerar se o VPC Service Controls faz sentido no ambiente delas.

5. Model Armor: ative o Model Armor para detectar e bloquear possíveis ataques de injeção de comandos de dados acessados pelos servidores MCP gerenciados do Google.