Prácticas recomendadas para proteger las interacciones de los agentes con el Protocolo de contexto del modelo

MySQL | PostgreSQL | SQL Server

El Protocolo de contexto del modelo (MCP) estandariza la forma en que los agentes de IA generativa se conectan a Cloud SQL para SQL Server. Debido a los riesgos inherentes de los agentes autónomos, la mitigación de vulnerabilidades como la inyección de instrucciones requiere un modelo de responsabilidad compartida que combine controles de plataforma con un diseño de aplicación seguro.
Para diseñar e implementar aplicaciones de IA que usen Google Cloud herramientas del Protocolo de contexto del modelo (MCP), sigue las prácticas recomendadas de esta guía.

Antes de comenzar

Cuando usas herramientas de MCP, la postura de seguridad de tu aplicación depende del modelo de interacción del agente. Para obtener información sobre cómo el uso de agentes afecta los riesgos de seguridad asociados con la integración de agentes con un servidor de MCP, consulta Seguridad y protección de la IA.

Responsabilidades de seguridad

Como cliente, eres responsable de la configuración y el funcionamiento seguros de tu plataforma de agentes.

Sigue el principio de privilegio mínimo.

Ejecuta tu agente con una cuenta de servicio de alcance mínimo. Esta es la primera y más importante capa de defensa.

Identidad dedicada: Crea una cuenta de servicio independiente y dedicada para cada agente o aplicación únicos que usen herramientas de MCP. No vuelvas a usar las SA existentes, en especial las que tienen permisos amplios.
Alcances mínimos: Otorga a la cuenta de servicio solo los roles necesarios de Identity and Access Management (IAM), por ejemplo, alloydb.viewer, no alloydb.admin. Si el agente solo necesita acceso de lectura a un conjunto de datos específico, usa roles de IAM personalizados para restringir el acceso al mínimo absoluto necesario para su función.
Separación de tareas: Si un agente necesita acceso de lectura a los datos y acceso de escritura a un registro o almacenamiento temporal, usa dos cuentas de servicio independientes: una cuenta para el acceso a datos de alto riesgo (con alcance mínimo) y una para tareas operativas de bajo riesgo.

Usa controles detallados nativos de la base de datos

Para obtener la defensa más sólida, combina los roles de IAM con los controles de acceso detallados que ofrece la propia base de datos. Esto garantiza que, incluso si un atacante vulnera el token de IAM del agente, el alcance del daño esté limitado por los permisos internos del motor de base de datos, por ejemplo, para evitar un comando DROP TABLE.

Producto	Mecanismo de control detallado	Enfoque
Cloud SQL y AlloyDB	Roles a nivel de la base de datos, como CREATE ROLE en PostgreSQL y MySQL	Administra los permisos en una instancia y esquemas de base de datos específicos.
BigQuery	Control de acceso a nivel de columna (con etiquetas de política)	Restringe el acceso del agente a columnas sensibles, por ejemplo, PII, incluso en una tabla autorizada.
Spanner	Control de acceso detallado (roles de base de datos con `GRANT/REVOKE`)	Aplica permisos precisos de lectura, escritura y actualización en tablas y columnas.
Firestore	Roles y condiciones de IAM	Configura permisos de acceso por base de datos con roles y condiciones de IAM.
Bigtable	Roles de IAM	Bigtable ofrece un control detallado a través de roles de IAM a nivel de proyecto, instancia y tabla.

Diseño de agentes seguros

Los modelos solo para agentes requieren defensas sólidas a nivel de la aplicación contra ataques de inyección de instrucciones, que intentan anular la instrucción del sistema. Para obtener más información, consulta Seguridad y protección de la IA.

Trata los datos y las entradas del usuario como no confiables

Trata como no confiables las entradas de los usuarios finales o los datos que el agente recupera de fuentes externas, como un resultado de búsqueda web o un documento de terceros.

Implementa patrones de selección de acciones

Evita las arquitecturas de planificación y ejecución abiertas, en las que el sistema desacopla la especificación de tareas de alto nivel de la ejecución mecánica. En su lugar, usa patrones de diseño que limiten la libertad del modelo.

Patrón de selector de acciones: El único trabajo del modelo es traducir una solicitud del usuario en una de un conjunto pequeño y predefinido de funciones seguras. La lógica de acción está codificada y el LLM no puede modificarla. Esto ayuda a que el agente sea inmune a los ataques de inyección dirigidos al flujo de control.
Patrón de LLM doble: Usa un LLM principal (el LLM de acción) que realiza la tarea principal y un LLM secundario y altamente seguro (el LLM de protección) que analiza previamente la instrucción del usuario en busca de intenciones maliciosas y analiza posteriormente el resultado del LLM de acción en busca de acciones no autorizadas o filtración de datos.

Evita el encadenamiento de herramientas no autorizado

Los agentes solo deben llamar a las herramientas que sean necesarias para la tarea. Asegúrate de que tu código de organización evite lo siguiente:

Herramientas dinámicas: El agente no debe poder registrar dinámicamente herramientas nuevas ni cambiar los permisos de las herramientas existentes.
Aplicación de la lista de entidades permitidas: Declara una lista de entidades permitidas de funciones o tablas de bases de datos a las que el agente puede acceder en su instrucción inicial del sistema y código de backend. Para obtener un ejemplo de la CLI de Gemini, consulta Restricción del acceso a las herramientas.

Limita el acceso a los datos en bases de datos de múltiples usuarios

Una herramienta general como execute_sql permite que el llamador ejecute consultas de bases de datos que pueden leer cualquier dato al que IAM y los permisos de la base de datos permitan el acceso. Cuando creas un agente que accede a datos en una aplicación de múltiples usuarios sin una persona de confianza en el circuito, es posible que debas limitar aún más el acceso a los datos.

Para asegurarte de que el agente solo pueda leer subconjuntos de los datos a los que tiene acceso, te recomendamos que crees herramientas personalizadas con un framework como MCP Toolbox para bases de datos. Para obtener más información, consulta Herramientas precompiladas y personalizadas.

Por ejemplo, imagina que tu base de datos almacena pedidos de todos los usuarios finales en la tabla Orders. Estás desarrollando un agente de chat que interactúa con los usuarios y puede buscar sus pedidos. El agente de chat tiene permiso para leer toda la tabla Orders, pero un usuario final no debe poder solicitar información sobre los pedidos de otro usuario.

En una situación insegura, equipas al agente solo con una herramienta execute_sql, lo que crea un riesgo de filtración de datos. Un usuario malicioso puede engañar al agente para que lea y muestre los pedidos de otros usuarios. Por lo general, no es suficiente indicarle al agente que aplique las reglas de acceso para proteger los datos.

En una situación segura, le das al agente una herramienta personalizada más específica, como lookup_active_order, en la que la identidad del usuario en el filtro de consulta se establece fuera del control del agente.

Parámetros de configuración de seguridad y protección

Cloud SQL para SQL Server proporciona Model Armor para aplicar límites de seguridad a nivel de la plataforma. Debes habilitar y configurar estos parámetros.

Habilita Model Armor

Usa la CLI de gcloud para habilitar Model Armor en la implementación de tu modelo. Esto activa la protección integrada contra vectores de ataque conocidos, como la inyección y el jailbreak.

En el siguiente ejemplo, se habilita Model Armor en un extremo de Vertex AI.

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

Para obtener más información y ejemplos, consulta Configura la protección de Model Armor para MCP en Google Cloud.

Aplica umbrales de seguridad mínimos para las operaciones de datos sensibles

Model Armor te permite aplicar un umbral de seguridad mínimo para las operaciones de datos sensibles, por ejemplo, la detección y la desidentificación de información de identificación personal (PII). Usa un DeidentifyTemplate de Sensitive Data Protection para redactar o enmascarar información sensible antes de que se muestre al usuario, incluso si el modelo está vulnerado.

A continuación, se muestra un ejemplo conceptual de configuración:

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

En el siguiente ejemplo, model_armor_config.json podría hacer referencia a una plantilla de DLP:

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

Auditoría y observabilidad

La visibilidad de las acciones del agente es fundamental para el análisis posterior a los incidentes y la detección de agentes vulnerados.

Implementa una estrategia de recuperación de datos

Si bien los controles en capas, como los roles nativos de IAM y de la base de datos, están diseñados para evitar acciones destructivas, debes tener un plan de recuperación en caso de que fallen esas defensas. Un agente vulnerable o ingenuo con permisos de escritura (un riesgo "solo para agentes") podría ser engañado para ejecutar un comando destructivo como DROP TABLE o dañar datos.

Tu defensa principal contra esta situación es una estrategia de recuperación sólida.

Casi todos los productos de Data Cloud proporcionan funciones para la recuperación de datos, ya sea a través de copias de seguridad tradicionales, recuperación de un momento determinado (PITR) o instantáneas de datos. Eres responsable de habilitar y configurar estas funciones.

Producto	Mecanismos de copia de seguridad y recuperación
Cloud SQL	Admite copias de seguridad automáticas y a pedido, lo que te permite restablecer una instancia a un estado anterior. También admite la recuperación de un momento determinado (PITR).
AlloyDB	Proporciona copia de seguridad y recuperación continuas de forma predeterminada. Esto habilita la PITR con una granularidad de microsegundos, lo que te permite restablecer un clúster a cualquier momento de tu período de retención.
BigQuery	La recuperación de datos se logra con "Viaje en el tiempo", que te permite acceder a los datos y restablecerlos desde cualquier punto de los últimos 7 días. Para la retención a largo plazo, puedes crear instantáneas de tabla.
Spanner	Admite copias de seguridad a pedido y PITR.
Firestore	Admite copias de seguridad automáticas que te permiten restablecer una base de datos a un estado anterior. También ofrece PITR para proteger contra escrituras o eliminaciones accidentales. Ambas funciones están inhabilitadas de forma predeterminada.
Bigtable	Admite copias de seguridad automáticas y a pedido. Estas copias de seguridad están completamente administradas y se pueden restablecer en una tabla nueva.

Habilita los registros de auditoría de Cloud

Asegúrate de que los registros de auditoría deacceso a los datos estén habilitados para MCP, así como para todos los Google Cloud servicios relevantes, como BigQuery, Cloud SQL, AlloyDB, Firestore y Spanner. De forma predeterminada, solo están habilitados los registros de auditoría de actividad del administrador. Los registros de auditoría de acceso a los datos registran cada operación de lectura y escritura que realiza el agente. Para obtener más información, consulta Registros de auditoría de acceso a los datos para MCP.

Audita las acciones sensibles

Configura alertas en Cloud Logging para detectar acciones anómalas o de alto riesgo. La consulta del Explorador de registros identifica las cuentas de servicio que realizan operaciones de escritura de datos en Firestore, por ejemplo, que es un objetivo común para la exfiltración o los ataques destructivos:

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"

Usa el registro específico del agente

Además de los registros de auditoría de Cloud, asegúrate de que el código de tu aplicación registre los siguientes datos para cada decisión del agente:

Ejecución de herramientas: La herramienta de MCP a la que se llamó.
Comando sin procesar: El comando exacto, por ejemplo, una consulta SQL o una ruta de acceso al documento, que genera el LLM.
Acción final: Si la acción se ejecuta (modelo solo para agentes) o se aprueba (persona en el medio). Para obtener más información, consulta Comprende el uso del agente.
ID de usuario y sesión: El identificador del usuario final que inició la solicitud.