Seguridad¶

Peligro

Este módulo puede ser peligroso si no se configura con cuidado.

Un LLM conectado a Odoo puede, según lo que habilite:

Exfiltrar datos hacia un proveedor de modelos externo (los prompts, los resultados de las herramientas, los archivos adjuntos y el historial de conversación salen de su servidor).
Leer cualquier dato de negocio que el usuario que actúa (o el usuario de agente) ya pueda leer según las ACL de Odoo — y, por defecto, la política de acceso de la IA permite la lectura salvo que la restrinja.
Crear, modificar o eliminar registros en cuanto las capacidades de escritura/eliminación y las reglas de la política de acceso lo permitan — incluso mediante ejecuciones de agente sin supervisión (tras la aprobación de una propuesta por parte del supervisor, o de inmediato si el Modo de escritura de esa tarea es híbrido o automático), o al instante en el chat con el modo de escritura Aplicar automáticamente.
Ejecutar acciones de negocio (métodos de ciclo de vida) si la capacidad de Acción y la lista de permitidos lo autorizan.
Acceder a la web pública o a herramientas MCP, lo que puede introducir contenido no confiable en el contexto del modelo (inyección de prompts) o enviar datos hacia el exterior.
Modificar la interfaz y el esquema si la personalización (Customize) está habilitada para un administrador.

Trate cada privilegio de IA como un acceso root de producción para ese ámbito: empiece de forma restringida, mida y abra solo lo que un caso de uso concreto necesite.

Modelo de amenazas (qué puede salir mal)¶

Datos que salen de la empresa¶

Cada turno de chat y cada resultado de herramienta que se envía al proveedor se procesa según los términos y la jurisdicción de ese proveedor. Los datos personales sensibles, los salarios, las contraseñas (si alguna vez aparecen en texto libre), las condiciones contractuales y los secretos de los clientes pueden aparecer en:

el mensaje del usuario y el historial de conversación;
las instantáneas de registro L4 al chatear desde un formulario;
los resultados de las herramientas (resultados de search / read / read_group);
los archivos subidos y las páginas web obtenidas;
los pasos de ejecución del agente y los registros con la carga completa (si el registro está configurado en carga completa).

Mitigaciones: elija un proveedor y una región que acepte contractualmente; mantenga el Nivel de registro de IA en Solo metadatos en producción salvo que esté investigando un incidente; deniegue los modelos o campos sensibles en las reglas de acceso de IA; no habilite Web ni MCP para agentes que gestionen tickets confidenciales; forme a los usuarios para que no peguen secretos en el chat.

Chat interactivo con privilegios excesivos¶

Si un empleado con privilegios elevados utiliza el asistente con Escritura, Eliminación o Acción habilitadas y el modo de escritura Aplicar automáticamente, un único turno erróneo del modelo (o una inyección de prompt en un correo pegado) puede modificar los datos de producción de inmediato.

Mitigaciones: mantenga el modo de escritura en híbrido o confirmar; deje la Eliminación desactivada; restrinja la Escritura a grupos de confianza mediante la capacidad Restringido a grupos; establezca reglas de denegación de campo o modelo para la nómina, los bancos, los impuestos y los modelos del sistema.

Agente autónomo con privilegios excesivos¶

Un agente vinculado a un res.users se ejecuta con los grupos de Odoo de ese usuario. Si copia los valores predeterminados de «Usuario interno» sin eliminar grupos, el agente es un empleado con todos los permisos. Combinado con un ámbito de canal agent_full y una audiencia amplia, cualquier solicitante de la lista de permitidos puede desencadenar trabajo con todas las clases de capacidad del agente.

Mitigaciones: cree un usuario dedicado con solo los grupos necesarios; nunca vincule Ajustes ni Administrador de IA; establezca un supervisor humano; utilice el ámbito intersect por defecto; una audiencia de canal vacía significa nadie; mantenga la capacidad de Escritura desactivada en los agentes de cara al público; revise siempre las propuestas como supervisor.

Elusión del ciclo de vida o del estado¶

Escribir directamente en el campo state puede saltarse botones como Confirmar o Contabilizar. La puerta rechaza las escrituras directas al ``state`` del ciclo de vida. En su lugar, utilice acciones de negocio de la lista de permitidos (call_action) cuando la capacidad de Acción esté habilitada.

Suelo de denegación estricta (autoprotección)¶

Un conjunto fijo de modelos técnicos está siempre denegado para las herramientas de IA, con independencia de las reglas de acceso. Los administradores no pueden «abrirlos» mediante ai.access.rule. El suelo incluye:

los modelos del sistema sensibles para la seguridad (derechos de acceso, reglas, grupos, usuarios y claves API, parámetros de configuración, secuencias, menús, vistas, acciones de servidor, crons, cola de correo, tokens de pago, cuentas bancarias de los contactos, …);
todos los modelos de la propia aplicación de IA (ai y cualquier nombre ai.*) — los agentes no pueden reconfigurar la política, las habilidades, los bloqueos ni sus propias ejecuciones mediante herramientas;
mail.message y discuss.channel en bruto (autoría e integridad de las pruebas — el chatter legítimo pasa por el message_post del registro propietario, no por herramientas genéricas de creación).

Esto es un suelo, no una política completa de clasificación de datos — los modelos de negocio como hr.employee o account.move no están denegados de forma estricta por defecto; debe configurarlos si lo necesita.

ir.attachment y mail.activity quedan justo fuera del suelo, en un pequeño conjunto de permiso solo explícito: ningún valor global por defecto los abre nunca, pero una regla de acceso sí puede hacerlo, y el módulo incluye una para cada uno — los adjuntos son legibles y escribibles, y las actividades son legibles, escribibles y creables — de modo que las habilidades de documentos y de facturas de proveedor pueden leer un PDF y los agentes pueden dejar una tarea de revisión con su propio nombre. Crear o eliminar un adjunto, y eliminar una actividad, permanecen cerrados, porque ninguno de los dos modelos llega a los valores globales por defecto. Interprete esas dos reglas como permisos reales y no como parte del suelo: un agente puede crear una actividad en cualquier registro que pueda leer, y puede volver a adjuntar un archivo a otro registro. Restrínjalas o desactívelas si eso es más de lo que necesita la implantación.

Efectos secundarios entre modelos¶

Un campo puede escribir en un modelo que usted nunca abrió: crm.lead.email_from actualiza el correo electrónico del contacto. La puerta rechaza esos campos, y los dos tipos de cruce no son igual de configurables. Cuando el cruce es estático — un campo related —, el rechazo es absoluto y ninguna regla de acceso lo levanta. Cuando es dinámico — un campo que lleva un inverse —, solo se levanta mediante una regla que nombre ese campo exacto, de modo que una concesión a nivel de modelo no pueda filtrarse de lado y el registro de auditoría no pueda subestimar en silencio lo que tocó una escritura. En la ruta de obtención de archivos (fetch_file_to_field) la activación por campo no se aplica en absoluto: un campo de destino que lleva un inverse se rechaza sea cual sea la regla que escriba, porque el contenido procede de una URL elegida por el modelo.

El módulo incluye diez permisos de escritura limitados a un campo habilitados de fábrica en las bases de datos con Contabilidad, para el flujo de facturación. Cuatro están en account.move.line, y en la ruta one2many anidada un Allow a nivel de campo se resuelve antes que el nivel de modelo, de modo que esos cuatro campos de línea son escribibles a través de Líneas de factura aunque ninguna regla permita escribir en el propio account.move.line. Revíselos antes de certificar que las líneas de factura están cerradas. Uno de los cuatro, analytic_distribution, requiere especial atención: es un campo JSON, por lo que su regla levanta tanto el rechazo de los valores de tipo JSON como la barrera entre modelos, y su inverse reescribe los apuntes analíticos de una línea contabilizada — eliminando y volviendo a crear registros de account.analytic.line en un modelo que ninguna regla nombró. Véase Protección de escritura entre modelos.

Eliminación de campos sensibles¶

Los campos cuyos nombres parecen secretos (password, token, api_key, …), los campos mágicos y ciertos tipos complejos se eliminan o se rechazan al escribir. Esto es defensa en profundidad, no un sustituto de denegar modelos completos (por ejemplo, RR. HH.).

Confirmación y nueva comprobación¶

Las escrituras pendientes se vuelven a validar en el momento de aplicarlas, con la identidad de actuación correcta y la política vigente. Aprobar una propuesta antigua después de que se hayan revocado los derechos debe fallar de forma cerrada. Las propuestas de agente reconstruyen su autoridad a partir de la ejecución, no a partir del privilegio de quien confirma (quien confirma autoriza; el agente ejecuta).

La propia vigencia de la ejecución forma parte de esa autoridad. Una propuesta de una ejecución que se detuvo a petición, o que el recolector de ejecuciones atascadas cerró porque su worker murió, se rechaza al aplicarla y nadie puede aprobarla: el recolector no puede distinguir un worker muerto de uno lento, así que nunca se permite reproducir las escrituras de una ejecución que otro declaró terminada. Las propuestas dejadas por una ejecución que terminó por sí misma — Hecha, Fallida o Tiempo agotado — siguen siendo aprobables hasta que el mantenimiento las hace caducar.

Roles y grupos de seguridad¶

Grupo	Finalidad
IA: Usuario	Usar el chat, sus propias conversaciones, sus propias propuestas de escritura y la memoria; los supervisores necesitan esto para aprobar las propuestas de los agentes.
IA: Administrador	Configurar agentes, capacidades, políticas, habilidades, MCP y supervisión. Implica IA: Usuario.
Ajustes (administración del sistema)	Página de ajustes de la aplicación de IA, configuración guiada, planes de configuración.

Importante

Un usuario de agente nunca debe tener Ajustes ni Administrador de IA. El módulo bloquea la vinculación de esos usuarios en el formulario del agente (al escribir). Tampoco conceda esos grupos más tarde en el formulario del usuario — eso elude la restricción del agente y elimina el interruptor de bloqueo de emergencia para los administradores de IA.

Controles por capas (lista de comprobación)¶

Utilice todas las capas; ninguna sustituye a las demás:

Grupos de Odoo del usuario o del usuario de agente — lo que pueden hacer sin la IA.
Capacidades de IA — qué clases de herramientas existen (ask, read, write, delete, web, mcp, action, customize, setup, navigate).
Grupos de acceso de IA + reglas — permiso o denegación por modelo/campo para las herramientas de IA.
``capability_ids`` del agente — un límite adicional solo para ese agente.
Reglas de canal + audiencia + scope_mode — quién puede activar al agente y si las clases de capacidad se cruzan con las del solicitante.
Modo de escritura / escrituras pendientes / supervisor — una persona en el proceso. El chat usa el modo global de Ajustes; cada tarea de agente tiene su propio modo (por defecto, confirmar). Véase Modo de escritura de la tarea (solo ejecuciones de agente).
Límites de frecuencia, avisos, bloqueos, patrones bloqueados — abuso e iteración.
Registro y retención — pruebas y retención mínima para los registros de pasos.

Base recomendada para producción¶

Deje Escritura, Eliminación, Web, MCP, Personalizar y Acción desactivadas hasta que un caso de uso concreto necesite cada una.
Mantenga los valores por defecto de la política de acceso: lectura permitida (o denegada si prefiere denegar por defecto y abrir solo los modelos necesarios), creación, escritura y eliminación denegadas.
Prefiera el modo de escritura híbrido o confirmar para el chat; nunca use automático en bases de datos de producción compartidas sin un proceso de gestión de cambios.
Deje el Modo de escritura de la tarea del agente en confirmar, salvo que la tarea sea explícitamente segura en borrador (por ejemplo, un cumplimentado de cuentas a pagar que nunca contabiliza); documente esa activación.
Un supervisor humano por agente; los supervisores deben estar en IA: Usuario.
Nada de un agente «todopoderoso» compartido para todos los departamentos — divida por dominio y por datos.
Revise IA ‣ Supervisión ‣ Infracciones semanalmente al principio.
Documente cada agente en su manual de procedimientos interno (finalidad, grupos de usuarios, reglas, clases de datos permitidas).

Lo que la seguridad no garantiza¶

Una resistencia perfecta a la inyección de prompts.
La clasificación de todos los campos de negocio sensibles de fábrica.
Que las conjeturas basadas en los datos de entrenamiento no puedan aparecer en las respuestas de texto libre (las reglas de fundamentación reducen, pero no eliminan, las alucinaciones — las acciones críticas deben pasar por herramientas y confirmación).
El cumplimiento del RGPD o legal por sí solo — sigue necesitando una base legítima, acuerdos de tratamiento de datos (DPA) con los proveedores y una política de retención para las conversaciones que conserve.

Continúe con Primeros pasos solo después de que esta página la comprendan las personas que administrarán el módulo.