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

MySQL   |  PostgreSQL   |  SQL Server

Pré-lançamento

Este 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 assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

O Protocolo de Contexto de Modelo (MCP) padroniza a forma como os agentes de IA generativa se conectam ao Cloud SQL para MySQL. 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 design de aplicativos seguros.
Para projetar e implantar aplicativos de IA que usam ferramentas do Protocolo de Contexto de Modelo (MCP), siga as práticas recomendadas neste guia. Google Cloud

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 sua plataforma de agente.

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

Execute o agente com uma conta de serviço com 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 usando as ferramentas do MCP. Não reutilize SAs, principalmente 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 absoluto necessário para a função dele.
• Separação de funções: 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 granular oferecidos pelo próprio banco de dados. Isso garante que, mesmo que um invasor comprometa o token do IAM do agente, o escopo do dano seja limitado pelas permissões internas do mecanismo de banco de dados. Por exemplo, isso impede que um DROP TABLE

Produto	Mecanismo de controle granular	Foco
Cloud SQL e AlloyDB	Funções no nível do banco de dados, como CREATE ROLE no PostgreSQL e MySQL.	Gerenciar permissões em uma instância de banco de dados e esquemas específicos.
BigQuery	Controle de acesso no nível da coluna (usando tags de política)	Restrinja o acesso do agente a colunas sensíveis, como PII, mesmo em uma tabela autorizada.
Spanner	Controle de acesso granular (papéis de banco de dados com GRANT/REVOKE)	Aplique permissões precisas de leitura/gravação/atualização em tabelas e colunas.
Firestore	Regras de segurança do Firestore	Restrinja o acesso no nível do documento ou do campo com base na lógica do aplicativo ou no contexto do usuário solicitante.
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 da IA.

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

Trate como não confiáveis as entradas 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.

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

Evite arquiteturas de planejamento e execução em aberto, em que o sistema separa a especificação de tarefas de alto nível da execução mecânica. Em vez disso, use padrões de design que limitam a liberdade do modelo.

• Padrão de seleção de ação:a única tarefa do modelo é traduzir uma solicitação do usuário em um 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 que visam o fluxo de controle.
• Padrão de LLM duplo:use um LLM principal (o LLM de ação) que realiza a tarefa principal e um LLM secundário altamente seguro (o LLM de proteção) que faz uma triagem prévia do comando do usuário para detectar intenções maliciosas e uma triagem posterior da saída do LLM de ação para detectar 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 de forma dinâmica 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 inicial do sistema e no código do back-end. Para um exemplo da CLI do Gemini, consulte Restringir o acesso a ferramentas.

Configurações de segurança

O Cloud SQL para MySQL oferece o Model Armor para aplicar limites de segurança no nível da plataforma. É necessário ativar e configurar essas opções.

Ativar o Model Armor

Use a CLI gcloud 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 jailbreak.

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 no Google Cloud.

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

Com o Model Armor, é possível aplicar um limite mínimo de segurança para operações com dados sensíveis, como detecção e remoção de identificação de informações de identificação pessoal (PII). Use uma DeidentifyTemplate da Proteção de dados sensíveis 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 da 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 o IAM e os papéis nativos 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 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 da Data Cloud oferecem recursos para 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	Aceita backups sob demanda e automatizados, permitindo restaurar uma instância para um estado anterior. Ele também é compatível com recuperação pontual (PITR).
AlloyDB	Fornece backup e recuperação contínuos por padrão. Isso ativa 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, crie snapshots de tabelas.
Spanner	Oferece suporte a backups sob demanda e PITR.
Firestore	Oferece suporte a exportações/importações gerenciadas como backups. Ela também oferece PITR, que está desativada por padrão, para proteger contra exclusões ou gravações acidentais.
Bigtable	Suporta 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 e Spanner. Por padrão, apenas os registros de auditoria de atividade do administrador sã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 do Explorador de registros identifica contas de serviço que realizam operações de gravação de dados no Firestore, por exemplo, que é um alvo comum para exfiltração ou ataques 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 o registro específico 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 caminho do documento, gerado pelo LLM.
• Ação final:se a ação é executada (modelo somente do agente) ou aprovada (Human-in-the-Middle). 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.