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, mitigar las vulnerabilidades, como la inyección de instrucciones, requiere un modelo de responsabilidad compartida, que combine los controles de la plataforma con el diseño seguro de las aplicaciones.
Para diseñar e implementar aplicaciones de IA que usen herramientas del Protocolo de contexto del modelo (MCP) de Google Cloud , 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 con permisos mínimos. Esta es la primera capa de defensa y la más importante.

• Identidad dedicada: Crea una cuenta de servicio independiente y dedicada para cada agente o aplicación únicos que usen herramientas de MCP. No reutilices las SA existentes, en especial aquellas con permisos amplios.
• Permisos mínimos: Otorga a la cuenta de servicio solo los roles de Identity and Access Management (IAM) necesarios, 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 funciones: 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 un alcance mínimo) y otra para las 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 base de datos. Esto garantiza que, incluso si un atacante vulnera el token de IAM del agente, el alcance del daño se limita por los permisos internos del motor de base de datos, por ejemplo, evitando 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 permisos en una instancia de base de datos y esquemas específicos.
BigQuery	Control de acceso a nivel de columna (con etiquetas de política)	Restringir el acceso de los agentes a las columnas sensibles, por ejemplo, de PII, incluso en una tabla autorizada
Spanner	Control de acceso detallado (roles de base de datos con GRANT/REVOKE)	Aplicar 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 de	Bigtable ofrece un control detallado a través de roles de IAM a nivel de proyecto, instancia y tabla.
Oracle Database@Google Cloud	Roles de IAM de	Oracle Database@Google Cloud ofrece un control detallado a través de roles de IAM a nivel de proyecto y de recurso.

Diseño de agentes seguro

Los modelos de solo agente requieren defensas sólidas a nivel de la aplicación contra los 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 de los usuarios como no confiables

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

Implementar patrones de selección de acciones

Evita las arquitecturas de planificación y ejecución abiertas, en las que el sistema desvincula 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 la acción está hard-coded y el LLM no puede modificarla. Esto ayuda a que el agente sea inmune a los ataques de inyección que se dirigen al flujo de control.
• Patrón de LLM doble: Usa un LLM principal (el LLM de acción) que realice la tarea principal y un LLM secundario y altamente seguro (el LLM de barrera de protección) que preseleccione la instrucción del usuario para detectar intenciones maliciosas y que, luego, filtre el resultado del LLM de acción para detectar acciones no autorizadas o filtraciones 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 de forma dinámica 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 en el código de backend. Para ver un ejemplo de la CLI de Gemini, consulta Restringe el acceso a las herramientas.

Limita el acceso a los datos en bases de datos multiusuario

Una herramienta general como execute_sql permite que el emisor ejecute consultas de base de datos que pueden leer cualquier dato al que los permisos de IAM y de la base de datos permitan el acceso. Cuando creas un agente que accede a datos en una aplicación multiusuario sin una intervención humana de confianza, 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 compiladas previamente frente a personalizadas.

Por ejemplo, imagina que tu base de datos almacena pedidos para 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 no segura, equipas al agente solo con una herramienta de execute_sql, lo que crea un riesgo de filtración de datos. Un usuario malicioso puede engañar al agente para que lea y devuelva los pedidos de otros usuarios. Por lo general, indicarle al agente que aplique las reglas de acceso no es suficiente para proteger los datos.

En una situación segura, le proporcionas 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 establecer estos parámetros de configuración.

Habilita Model Armor

Usa la gcloud CLI 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.

Aplicar 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 desidentificación de información de identificación personal (IIP). Usa un DeidentifyTemplate de Sensitive Data Protection para ocultar o enmascarar información sensible antes de que se devuelva al usuario, incluso si el modelo está comprometido.

A continuación, se muestra un ejemplo conceptual de la 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 de los agentes 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 IAM y los roles nativos de la base de datos, están diseñados para evitar acciones destructivas, debes tener un plan de recuperación en caso de que esas defensas fallen. Un agente comprometido o ingenuo con permisos de escritura (un riesgo de "solo agente") podría ser engañado para que ejecute un comando destructivo como DROP TABLE o corrompa 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 un nivel de detalle de microsegundos, lo que te permite restablecer un clúster en cualquier momento de tu período de retención.
BigQuery	La recuperación de datos se logra con el "viaje en el tiempo", que te permite acceder a los datos de los últimos 7 días y restablecerlos. Para una retención a más largo plazo, puedes crear instantáneas de tablas.
Spanner	Admite copias de seguridad on demand y PITR.
Firestore	Admite copias de seguridad automatizadas 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 se administran por completo y se pueden restablecer en una tabla nueva.
Oracle Database@Google Cloud	Admite copias de seguridad automáticas y PITR.

Habilita los Registros de auditoría de Cloud

Asegúrate de que los registros de auditoría de acceso a los datos estén habilitados para el MCP y todos los servicios de Google Cloud pertinentes, como BigQuery, Cloud SQL, AlloyDB, Firestore, Spanner y Oracle Database@Google Cloud. 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 el robo de datos 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 la aplicación registre los siguientes datos para cada decisión del agente:

• Ejecución de la herramienta: Es la herramienta de MCP a la que se llamó.
• Comando sin procesar: Es el comando exacto, por ejemplo, una consulta de SQL o una ruta de acceso de documento, que genera el LLM.
• Acción final: Indica si la acción se ejecuta (modelo de solo agente) o se aprueba (modelo de humano en el medio). Para obtener más información, consulta Información sobre el uso de agentes.
• ID de usuario y de sesión: Es el identificador del usuario final que inició la solicitud.