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

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

Versión preliminar

Esta función está con sujeción a las "Condiciones de las Ofertas de la Fase Previa a la DG" de la sección Términos Generales del Servicio de los Términos Específicos del Servicio. Las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

El Protocolo de contexto del modelo (MCP) estandariza la forma en que los agentes de IA generativa se conectan a Firestore. 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 Google Cloud 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 en 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 un 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 las herramientas de MCP. No reutilices las SA existentes, en especial las que tienen permisos amplios.
• Alcances 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 personalizados de IAM 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 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 lograr 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 se limita a los permisos internos del motor de base de datos, por ejemplo, impidiendo un 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.	Administrar 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, la PII), incluso en una tabla autorizada.
Spanner	Control de acceso detallado (roles de base de datos conGRANT/REVOKE)	Aplicar permisos precisos de lectura, escritura y actualización en tablas y columnas
Firestore	Reglas de seguridad de Firestore	Restringe el acceso a nivel del documento o del campo según la lógica de la aplicación o el contexto del usuario solicitante.
Bigtable	Roles de IAM	Bigtable ofrece un control detallado a través de roles de IAM a nivel del proyecto, la instancia y la tabla.

Diseño de agentes seguros

Los modelos de solo 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 de la IA.

Considera que los datos y las entradas del usuario no son de confianza

Trata como no confiable la entrada 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 de final abierto, 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 la acción está codificada y el LLM no la puede modificar. 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 altamente seguro (el LLM de protección) que realiza una revisión previa de la instrucción del usuario para detectar intenciones maliciosas y una revisión posterior del resultado del LLM de acción para detectar 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 orquestación evite lo siguiente:

• Herramientas dinámicas: El agente no debe poder registrar herramientas nuevas de forma dinámica 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 del sistema inicial y en el código de backend. Para ver un ejemplo de la CLI de Gemini, consulta Cómo restringir el acceso a herramientas.

Configuraciones de seguridad

Firestore 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 Google Cloud 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 jailbreaking.

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 el MCP en Google Cloud.

Aplicar umbrales mínimos de seguridad para las operaciones con datos sensibles

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

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 al incidente 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 ingenuo o vulnerado con permisos de escritura (un riesgo de "solo agente") podría ser engañado para que ejecute un comando destructivo como DROP TABLE o dañe datos.

Tu defensa principal ante 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 a cualquier momento dentro de tu período de retención.
BigQuery	La recuperación de datos se logra con la función "Viaje en el tiempo", que te permite acceder a los datos y restablecerlos desde cualquier punto en los últimos 7 días. Para la retención a largo plazo, puedes crear instantáneas de tablas.
Spanner	Admite copias de seguridad a pedido y PITR.
Firestore	Admite exportaciones e importaciones administradas como copias de seguridad. También ofrece la recuperación de un momento determinado (PITR), que está inhabilitada de forma predeterminada, para proteger contra escrituras o eliminaciones accidentales.
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.

Habilita Cloud Audit Logs

Asegúrate de que los registros de auditoría de acceso a los datos estén habilitados para MCP, así como para todos los Google Cloud servicios relevantes, como BigQuery, Cloud SQL, AlloyDB 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 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 la herramienta: Es la herramienta de MCP a la que se llamó.
• Comando sin procesar: Es el comando exacto (por ejemplo, una consulta en SQL o una ruta de acceso a un documento) que genera el LLM.
• Acción final: Indica si la acción se ejecuta (modelo solo para el agente) o se aprueba (humano en el medio). Para obtener más información, consulta Información sobre el uso del agente.
• ID de usuario y sesión: Es el identificador del usuario final que inició la solicitud.