Práticas recomendadas para proteger as interações do agente com o Protocolo de Contexto de Modelo

Visualização

Esse recurso está sujeito aos "Termos da oferta pré-GA" na seção "Termos gerais de serviço" dos Termos específicos de serviço. Os recursos 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 da fase de lançamento.

O Protocolo de Contexto de Modelo (MCP) padroniza como os agentes de IA generativa se conectam ao Bigtable. Devido aos riscos inerentes dos agentes autônomos, a mitigação de vulnerabilidades, como a injeção de comandos, exige um modelo de responsabilidade compartilhada, combinando controles de plataforma com um design de aplicativo seguro.
Para projetar e implantar aplicativos de IA que usam Google Cloud ferramentas do Protocolo de Contexto de Modelo (MCP), siga as práticas recomendadas neste guia.

Antes de começar

Ao usar ferramentas do MCP, a postura de segurança do aplicativo depende do modelo de interação do agente. Para saber como o uso de agentes afeta os riscos de segurança associados à integração de agentes com um servidor MCP, consulte Segurança e proteção de IA.

Responsabilidades de segurança

Como cliente, você é responsável pela configuração e operação seguras da plataforma do agente.

Siga o princípio de privilégio mínimo

Execute o agente com uma conta de serviço de escopo mínimo. Essa é a primeira e mais importante camada de defesa.

• Identidade dedicada:crie uma conta de serviço separada e dedicada para cada agente ou aplicativo exclusivo que usa ferramentas do MCP. Não reutilize as contas de serviço atuais, especialmente aquelas com permissões amplas.
• Escopos mínimos:conceda à conta de serviço apenas os papéis necessários do Identity and Access Management (IAM), por exemplo, alloydb.viewer, não alloydb.admin. Se o agente precisar apenas de acesso de leitura a um conjunto de dados específico, use papéis personalizados do IAM para restringir o acesso ao mínimo necessário para a função dele.
• Separação de tarefas : se um agente precisar de acesso de leitura aos dados e de gravação a um registro ou armazenamento temporário, use duas contas de serviço separadas: uma para acesso a dados de alto risco (com escopo mínimo) e outra para tarefas operacionais de baixo risco.

Usar controles granulares nativos do banco de dados

Para uma defesa mais forte, combine papéis do IAM com os controles de acesso granulares oferecidos pelo próprio banco de dados. Isso garante que, mesmo que um invasor comprometa o token do IAM do agente, o escopo de danos seja limitado pelas permissões internas do mecanismo de banco de dados, por exemplo, impedindo um comando DROP TABLE.

Produto	Mecanismo de controle granular	Foco
Cloud SQL e AlloyDB	Papéis no nível do banco de dados, como CREATE ROLE no PostgreSQL e MySQL.	Gerenciar permissões em uma instância e esquemas de banco de dados específicos.
BigQuery	Controle de acesso no nível da coluna (usando tags de política)	Restringir o acesso do agente a colunas sensíveis, por exemplo, PII, mesmo em uma tabela autorizada.
Spanner	Controle de acesso detalhado (papéis de banco de dados com GRANT/REVOKE)	Aplicar permissões precisas de leitura/gravação/atualização em tabelas e colunas.
Firestore	Papéis e condições do IAM	Configure permissões de acesso por banco de dados usando papéis e condições do IAM.
Bigtable	Papéis do IAM	O Bigtable oferece controle granular por meio de papéis do IAM nos níveis de projeto, instância e tabela.

Design de agente seguro

Os modelos somente de agente exigem defesas robustas no nível do aplicativo contra ataques de injeção de comandos, que tentam substituir o comando do sistema. Para mais informações, consulte Segurança e proteção de IA.

Tratar dados e entradas do usuário como não confiáveis

Trate a entrada de usuários finais ou os dados buscados pelo agente de fontes externas, como um resultado de pesquisa na Web ou um documento de terceiros, como não confiáveis.

Implementar padrões de seleção de ações

Evite arquiteturas planejar e executar abertas, em que o sistema desvincula a especificação de tarefas de alto nível da execução mecânica. Em vez disso, use padrões de design que limitem a liberdade do modelo.

• Padrão de seleção de ações:o único trabalho do modelo é traduzir uma solicitação do usuário em uma de um pequeno conjunto predefinido de funções seguras. A lógica de ação é codificada e não pode ser modificada pelo LLM. Isso ajuda a tornar o agente imune a ataques de injeção direcionados ao fluxo de controle.
• Padrão de LLM duplo:use um LLM principal (o LLM de ação) que executa a tarefa principal e um LLM secundário e altamente seguro (o LLM de proteção) que pré-seleciona o comando do usuário para detectar intenções maliciosas e pós-seleciona a saída do LLM de ação para ações não autorizadas ou vazamento de dados.

Impedir o encadeamento de ferramentas não autorizado

Os agentes só podem chamar ferramentas necessárias para a tarefa. Verifique se o código de orquestração impede o seguinte:

• Ferramentas dinâmicas:o agente não pode registrar novas ferramentas dinamicamente nem mudar as permissões das ferramentas atuais.
• Aplicação da lista de permissões:declare uma lista de permissões de funções ou tabelas de banco de dados que o agente pode acessar no comando do sistema inicial e no código de back-end. Para um exemplo da CLI do Gemini, consulte Restringir o acesso a ferramentas.

Limitar o acesso aos dados em bancos de dados multitenant

Uma ferramenta geral como execute_sql permite que o autor da chamada execute consultas de banco de dados que podem ler todos os dados que o IAM e as permissões do banco de dados permitem o acesso. Ao criar um agente que acessa dados em um aplicativo multitenant sem um human in the loop confiável, talvez seja necessário limitar ainda mais o acesso aos dados.

Para garantir que o agente só possa ler subconjuntos dos dados a que ele tem acesso, recomendamos que você crie ferramentas personalizadas usando uma framework como a MCP Toolbox for Databases. Para mais informações, consulte Ferramentas pré-criadas x personalizadas.

Por exemplo, imagine que seu banco de dados armazena pedidos de todos os usuários finais na tabela Orders. Você está desenvolvendo um agente de chat que interage com os usuários e pode pesquisar os pedidos deles. O agente de chat tem permissão para ler toda a tabela Orders, mas um usuário final não pode solicitar informações sobre os pedidos de outro usuário.

Em um cenário não seguro, você equipa o agente com apenas uma ferramenta execute_sql, criando um risco de vazamento de dados. Um usuário malicioso pode enganar o agente para ler e retornar os pedidos de outros usuários. Instruir o agente a aplicar as regras de acesso normalmente não é suficiente para proteger os dados.

Em um cenário seguro, você oferece ao agente uma ferramenta personalizada mais específica, como lookup_active_order, em que a identidade do usuário no filtro de consulta é definida fora do controle do agente.

Configurações de segurança e proteção

O Bigtable fornece o Model Armor para aplicar limites de segurança no nível da plataforma. É necessário ativar e configurar essas configurações.

Ativar o Model Armor

Use a Google Cloud CLI para ativar o Model Armor na implantação do modelo. Isso ativa a proteção integrada contra vetores de ataque conhecidos, como injeção e jailbreaking.

O exemplo a seguir ativa o Model Armor em um endpoint da Vertex AI.

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

Para mais informações e exemplos, consulte Configurar a proteção do Model Armor para MCP em Google Cloud.

Aplicar limites mínimos de segurança para operações de dados sensíveis

O Model Armor permite aplicar um limite mínimo de segurança para operações de dados sensíveis, por exemplo, detecção e desidentificação de informações de identificação pessoal (PII). Use um da Proteção de Dados Sensíveis DeidentifyTemplate para encobrir ou mascarar informações sensíveis antes que elas sejam retornadas ao usuário, mesmo que o modelo esteja comprometido.

Confira a seguir um exemplo conceitual de configuração:

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

No exemplo a seguir, model_armor_config.json pode fazer referência a um modelo de DLP:

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

Auditoria e observabilidade

A visibilidade das ações do agente é crucial para a análise pós-incidente e a detecção de agentes comprometidos.

Implementar uma estratégia de recuperação de dados

Embora os controles em camadas, como papéis nativos do IAM e do banco de dados, sejam projetados para evitar ações destrutivas, é necessário ter um plano de recuperação caso essas defesas falhem. Um agente comprometido ou ingênuo com permissões de gravação (um risco "somente de agente") pode ser enganado para executar um comando destrutivo como DROP TABLE ou corromper dados.

Sua principal defesa contra esse cenário é uma estratégia de recuperação robusta.

Quase todos os produtos do Data Cloud oferecem recursos de recuperação de dados, seja por backups tradicionais, recuperação pontual (PITR) ou snapshots de dados. Você é responsável por ativar e configurar esses recursos.

Produto	Mecanismos de backup e recuperação
Cloud SQL	Oferece suporte a backups automatizados e sob demanda, permitindo restaurar uma instância para um estado anterior. Ele também oferece suporte à recuperação pontual (PITR).
AlloyDB	Fornece backup e recuperação contínuos por padrão. Isso permite a PITR com granularidade de microssegundos, permitindo restaurar um cluster para qualquer momento na janela de retenção.
BigQuery	A recuperação de dados é feita usando a "Viagem no tempo", que permite acessar e restaurar dados de qualquer ponto nos últimos sete dias. Para retenção de longo prazo, é possível criar snapshots de tabelas.
Spanner	Oferece suporte a backups sob demanda e PITR.
Firestore	Oferece suporte a backups automatizados que permitem restaurar um banco de dados para um estado anterior. Ele também oferece PITR para proteger contra exclusões ou gravações acidentais. Esses dois recursos estão desativados por padrão.
Bigtable	Oferece suporte a backups automatizados e sob demanda. Esses backups são totalmente gerenciados e podem ser restaurados para uma nova tabela.

Ativar os registros de auditoria do Cloud

Verifique se os registros de auditoria de acesso a dados estão ativados para o MCP e todos os Google Cloud serviços relevantes, como BigQuery, Cloud SQL, AlloyDB, Firestore e Spanner. Por padrão, apenas os registros de auditoria de atividade do administrador estão ativados. Os registros de auditoria de acesso a dados registram todas as operações de leitura e gravação realizadas pelo agente. Para mais informações, consulte Registros de auditoria de acesso a dados para MCP.

Auditar ações sensíveis

Configure alertas no Cloud Logging para detectar ações anômalas ou de alto risco. A consulta da Análise de registros identifica contas de serviço que realizam operações de gravação de dados no Firestore, por exemplo, que é um destino comum para ataques de exfiltração ou destrutivos:

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

Usar a geração de registros específica do agente

Além dos registros de auditoria do Cloud, verifique se o código do aplicativo registra os seguintes dados para cada decisão do agente:

• Execução da ferramenta:a ferramenta do MCP que foi chamada.
• Comando bruto:o comando exato, por exemplo, uma consulta SQL ou um caminho de documento, gerado pelo LLM.
• Ação final:se a ação é executada (modelo somente de agente) ou aprovada (humano no meio). Para mais informações, consulte Entender o uso do agente.
• ID do usuário e da sessão:o identificador do usuário final que iniciou a solicitação.