Asegurar las llamadas a herramientas en chatbots de IA: permisos, confirmación y mecanismos de reversión

Un chatbot para sitios web cambia radicalmente en el momento en que no solo responde, sino que también puede activar acciones. Consultar una cita sigue siendo un proceso manejable. Sin embargo, cancelar una cita, cambiar una dirección o procesar un reembolso modifica el estado real del negocio. El modelo de lenguaje puede sugerir una llamada a una herramienta adecuada, pero debe ser una capa de aplicación independiente y determinista la que decida si la acción es admisible. Por lo tanto, las llamadas seguras a herramientas en chatbots de IA no se logran con un prompt de sistema especialmente estricto, sino mediante funciones limitadas, verificación de permisos en el servidor, una confirmación clara y un flujo de ejecución controlado.

Por qué un buen modelo de lenguaje no sustituye a la autorización

Un modelo trabaja con probabilidades. Puede malinterpretar una intencionalidad, añadir un parámetro innecesario o reaccionar a contenidos manipulados. La descripción de riesgos de OWASP sobre Excessive Agency identifica tres causas típicas: demasiada funcionalidad, permisos demasiado amplios y excesiva autonomía. Por lo tanto, el problema no es solo una entrada maliciosa. Incluso una solicitud ambigua o un error del modelo con apariencia plausible pueden preparar una acción no deseada.

Por este motivo, la regla de arquitectura más importante es: el modelo formula una propuesta, pero la aplicación la autoriza y la ejecuta. Una llamada a una herramienta como cancelAppointment es inicialmente solo una intención estructurada. Es necesaria una verificación de políticas (Policy Check) para evaluar al usuario, el inquilino (tenant), el objeto, la acción permitida, el estado actual y la confirmación requerida. Esta separación complementa la protección frente a Prompt Injection en chatbots para sitios web, y sigue siendo indispensable aunque no se haya detectado ningún ataque.

Clasificar cada herramienta por su impacto y no por su nombre

Los equipos no deben clasificar todo el chatbot de forma generalizada como "seguro" o "crítico". Lo decisivo es el impacto de cada herramienta individual. Una matriz de riesgo sencilla aporta claridad:

• De lectura y poco sensible: consultar horarios de apertura o información de productos de acceso público.
• De lectura y con datos personales: mostrar el estado de un pedido o datos del cliente; para ello se debe verificar la identidad, el inquilino y la relación con el objeto.
• De escritura, pero fácilmente reversible: registrar una solicitud interna de llamada o añadir una nota no vinculante.
• De alto impacto o difícilmente reversible: cancelar una reserva, modificar datos de contacto, publicar contenidos, enviar mensajes o iniciar pagos.

De esta clasificación se derivan los derechos, el nivel de confirmación, los límites y el registro de auditoría. Una aprobación generalizada como "El chatbot puede usar el CRM" es demasiado vaga. Es preferible contar con una lista de capacidades concretas con parámetros definidos y transiciones de estado permitidas.

El menor privilegio comienza en el diseño de las funciones

La Guía de autorización de OWASP recomienda el principio de menor privilegio (Least Privilege) y denegar por defecto (Deny by Default). Para las llamadas a herramientas, esto significa que el chatbot solo obtiene la función y el fragmento de datos necesarios para el paso correspondiente.

Herramientas pequeñas en lugar de interfaces universales

Una herramienta getOrderStatus(orderId) es más fácil de asegurar que un acceso abierto a la base de datos. Una herramienta requestCallback(topic, timeWindow) es más controlable que una función general para enviar mensajes arbitrarios. Las funciones libres de SQL, Shell, URL o correo electrónico amplían innecesariamente el impacto potencial. Asimismo, las herramientas de prueba que ya no se utilicen deben eliminarse del catálogo de producción.

Ejecutar en el contexto del usuario autenticado

El backend no debe confiar únicamente en que el modelo envíe el ID de cliente correcto. Debe derivar el usuario e inquilino actuales a partir de una sesión confiable y volver a verificar para cada objeto si existe permiso de acceso. La diferencia práctica entre un chat público y un área protegida se explica detalladamente en el artículo sobre identidad y acceso a datos en portales de clientes. Una cuenta de servicio general con acceso total suele ser un atajo incorrecto para acciones vinculadas al usuario.

Validar parámetros de forma determinista

Los parámetros de las herramientas necesitan un esquema estricto: campos permitidos, tipos, longitudes, rangos de valores y reglas de estado. El ID de una cita debe pertenecer al usuario, una fecha debe estar en un rango válido y una acción debe coincidir con el estado actual. Los campos desconocidos se rechazan. La aplicación también debe garantizar que el nombre de la herramienta provenga de una lista blanca (allowlist) fija y no se ejecute a partir de texto generado libremente.

La confirmación debe mostrar la acción real

En el caso de cambios de gran impacto, no basta con la pregunta "¿Está seguro?". La Guía de autorización de transacciones de OWASP describe el principio "Lo que ves es lo que firmas" (What You See Is What You Sign): los usuarios deben ser capaces de reconocer y confirmar los datos esenciales de la acción concreta. Para un chatbot en un sitio web, esto significa, por ejemplo:

• "Cancelar cita del 18 de agosto a las 14:30" en lugar de "Confirmar cambio"
• "Cambiar dirección de entrega del pedido ...84 a Madrid" en lugar de "Guardar datos"
• "Crear solicitud de llamada con el tema Facturación" en lugar de "Enviar solicitud"

La confirmación se vincula en el servidor exactamente a este borrador de acción. Si cambian el destino, el importe, la fecha, el destinatario u otros parámetros esenciales, la confirmación queda invalidada. Debe tener un periodo de validez corto y no se puede reutilizar para una segunda acción. Para procesos especialmente críticos, se puede requerir además un nuevo inicio de sesión o la aprobación de un operador humano. El modelo no debe omitir este paso ni sustituirlo por una respuesta de tono tranquilizador.

Planificar idempotencia, límites y rutas de reversión

Incluso una llamada a una herramienta correctamente autorizada puede llegar duplicada por razones técnicas: el navegador reintenta una solicitud, un tiempo de espera agotado (timeout) desencadena un reintento o el usuario envía el mismo mensaje otra vez. Por ello, las herramientas de escritura deben utilizar un ID de idempotencia en el servidor. Para el mismo ID, la misma acción se ejecuta como máximo una vez; un reintento recibe el resultado que ya se conocía.

Además, cada herramienta necesita límites adecuados: llamadas máximas por sesión, timeouts cortos, reintentos limitados y la interrupción ante secuencias inusuales. Antes de la ejecución, el backend vuelve a verificar el estado. De este modo, una reserva que ya ha sido cancelada no se procesará por segunda vez. Siempre que sea posible, la acción debe crearse inicialmente como borrador o solicitud pendiente. Para los cambios directos e inevitables, debe estar claro cómo se compensan, se revocan o se derivan a un equipo de soporte. Un plan preparado de modo degradado y reversión ante incidentes evita tener que improvisar en caso de fallo.

Registrar eventos sin recopilar datos confidenciales

Un registro de seguridad debe permitir responder quién autorizó qué acción, sobre qué base y con qué resultado se ejecutó. Es conveniente incluir un ID de actor seudonimizado, la herramienta y su versión, la referencia del objeto, la versión de la política, la decisión de autorización, el ID de confirmación, el ID de idempotencia, la marca de tiempo y el resultado. Las contraseñas, tokens, historiales de chat completos y datos personales innecesarios no deben incluirse en este registro.

La Guía de seguridad para agentes de IA de OWASP recomienda estructurar los datos de decisión para acciones de alto riesgo y separar la decisión de la ejecución. Esto es diferente del rastreo técnico completo (tracing): para una auditoría de seguridad, lo que cuenta es una prueba concisa y sólida de la cadena de aprobación. El almacenamiento y el acceso deben alinearse con las necesidades reales de auditoría.

Una arquitectura robusta en cinco capas

1. Diálogo y propuesta: El modelo identifica la intención y genera un borrador de acción estructurado, pero no ejecuta nada directamente.
2. Decisión de política: Un componente determinista verifica la lista blanca de herramientas, el usuario, el inquilino, el objeto, los parámetros, la clase de riesgo y los límites.
3. Confirmación: La interfaz muestra los datos esenciales de la acción. La aprobación es efímera y está vinculada al borrador sin modificaciones.
4. Ejecución: Un ejecutor estrictamente limitado vuelve a verificar la autorización inmediatamente antes de la llamada y utiliza un ID de idempotencia.
5. Evidencia y reacción: El resultado, los errores y la cadena de aprobación se registran minimizando el uso de datos; la alerta, la compensación y la transferencia a un agente humano están definidas.

El marco NIST AI RMF Core organiza estas tareas en Gobernar, Mapear, Medir y Gestionar. En la práctica, esto significa: definir responsabilidades y límites de riesgo, comprender el contexto de uso, probar los controles y reaccionar ante las desviaciones observadas.

Matriz de pruebas antes del lanzamiento

Las pruebas positivas por sí solas no bastan. Una herramienta también debe fallar de forma segura en condiciones desfavorables. Como mínimo, estos casos deben formar parte de una matriz de pruebas repetible:

• Un usuario no autenticado o no autorizado solicita la acción.
• Una sesión válida hace referencia a un objeto de otro inquilino.
• Los parámetros esenciales cambian después de la confirmación.
• La misma solicitud se repite debido a un timeout o a un doble clic.
• Una herramienta devuelve instrucciones manipuladas o campos adicionales inesperados.
• Una llamada supera los límites de tiempo, cantidad o coste.
• El sistema de destino falla entre la verificación y la ejecución.
• Se revoca un permiso justo antes de la ejecución.

No solo se esperan acciones exitosas, sino rechazos claros, datos inalterados y eventos de seguridad aprovechables. Antes de activar permisos de escritura para usuarios reales, se puede verificar el flujo en Shadow Mode con solicitudes reales, sin llegar a ejecutar las acciones propuestas.

Lista de verificación para equipos web

• ¿Cada herramienta es pequeña, tiene un propósito específico y proviene de una lista blanca fija?
• ¿Se verifican en el servidor el usuario, el inquilino, el objeto y la acción?
• ¿Se aplican la denegación por defecto y los permisos técnicos mínimos?
• ¿Los usuarios ven todos los datos esenciales antes de realizar acciones críticas?
• ¿La confirmación caduca ante cambios y tras un periodo corto?
• ¿Un ID de idempotencia evita la ejecución duplicada?
• ¿Existen límites, timeout, cancelación, compensación y transferencia a humanos?
• ¿Se mantienen los tokens, secretos y datos personales innecesarios fuera de los registros?
• ¿La matriz de pruebas cubre errores de permisos, manipulación, reintentos y caídas del sistema?

Conclusión: El modelo propone, la aplicación decide

Un chatbot para sitios web con capacidad de actuar no necesita comenzar con acceso total. Empiece con una acción estrictamente limitada y reversible, y construya la cadena de aprobación de forma transparente a su alrededor. Cuando el diseño de la herramienta, la autorización en el servidor, la confirmación concreta, la idempotencia y la ruta de reversión se diseñan de forma conjunta, el chat sigue siendo útil sin dar al modelo el rol de un sistema de seguridad. Para el siguiente paso, vale la pena realizar un taller con los equipos de producto, desarrollo, soporte y protección de datos: elija una acción real, clasifique su riesgo y defina el caso de rechazo seguro antes de la primera activación en producción.