Dar a un agente permiso de escritura en tu CRM
Un agente que solo lee produce una respuesta equivocada que alguien detecta. Un agente que escribe produce un registro equivocado que hereda todo lo que viene después. Cuatro controles marcan la diferencia.
Contenido
- Puntos clave
- Escribir no es leer con pasos adicionales
- La amenaza de diseño es la inyección, no el error
- Acota la credencial antes de escribir código
- Haz idempotente cada escritura
- Primero dry-run, y déjalo para siempre
- Decide qué acciones aprueba una persona
- El log de auditoría es el entregable
- Preguntas frecuentes
Un agente LLM puede escribir en un CRM con seguridad si existen cuatro controles. La credencial se acota a objetos y campos concretos, cada escritura lleva clave de idempotencia, el modo dry-run muestra el diff antes de aplicarlo y lo irreversible pasa por aprobación humana. Toda escritura queda en el log de auditoría.
Puntos clave
- La inyección de prompts no tiene solución fiable hoy. Conviene asumir que el agente acabará leyendo instrucciones hostiles en los datos que procesa.
- OWASP clasifica el riesgo de fondo como excessive agency: demasiada funcionalidad, demasiados permisos y demasiada autonomía. Los tres son decisiones de configuración.
- Las claves de idempotencia evitan que un reintento cree una segunda oportunidad para la misma operación. Un draft del IETF define la cabecera
Idempotency-Keyjusto para eso. - La CVE-2025-32711, publicada el 11 de junio de 2025, documenta una fuga por inyección de prompts sin interacción del usuario en un asistente en producción.
- El modo dry-run y un log de solo anexado cuestan unos días de trabajo y deciden si un incidente se puede explicar.
Escribir no es leer con pasos adicionales
Un agente de solo lectura que se equivoca produce una respuesta equivocada. Alguien lo nota y el registro sigue intacto. Un agente con permiso de escritura produce un registro equivocado, y el enrutamiento, el forecast y la comisión lo heredan en silencio.
Ese fallo se ve peor, porque nadie revisa 400 actualizaciones de campo. La pregunta no es si el modelo acierta lo suficiente, sino si el sistema que lo rodea reduce una escritura mala a algo localizable y reversible.
La amenaza de diseño es la inyección, no el error
La inyección de prompts encabeza el Top 10 de OWASP para aplicaciones con LLM. Su forma indirecta — instrucciones escondidas en el contenido que el modelo recupera — se documenta desde 2023 y las mitigaciones siguen siendo parciales.
Greshake y sus coautores describieron la inyección indirecta de prompts en febrero de 2023. El atacante planta instrucciones en datos que el modelo recuperará más tarde, sin necesitar acceso directo a la aplicación. Sus pruebas mostraron ejecución de código arbitrario en sistemas ya en producción (arXiv:2302.12173).
Un CRM está hecho de datos recuperados. Correos, formularios, notas de reunión y tickets llegan a la ventana de contexto. El triaje de Simon Willison hace visible la exposición: el riesgo se concentra cuando un sistema guarda datos privados, lee contenido no confiable y puede comunicarse hacia fuera. Un agente de CRM reúne los tres.
Acota la credencial antes de escribir código
Casi todas las plataformas de CRM emiten tokens por integración con permisos por objeto y por campo. El agente no necesita borrar cuentas ni el objeto de usuarios, y rara vez necesita más que unos pocos campos de leads, contactos y tareas.
La integración corre con identidad propia, nunca como usuario administrador. Y recibe herramientas estrechas, no un cliente de API genérico. Sobre update_lead_stage(lead_id, stage) se puede razonar y aplicar rate limit. Sobre call_api(method, path, body) no.
Haz idempotente cada escritura
Las redes agotan tiempos de espera, las colas reentregan y los modelos reintentan. Sin idempotencia, un reintento crea un contacto duplicado o una tarea repetida.
El draft del grupo HTTP API del IETF para la cabeceraIdempotency-Key, revisión 07 del 15 de octubre de 2025, define una clave generada por el cliente. Permite al servidor reconocer un reintento ya procesado, de modo que métodos comoPOSTtoleren fallos (IETF Datatracker).
La clave se deriva de la operación, no del intento: identificador del registro, cambio previsto y ventana temporal. Si la plataforma ignora la cabecera, conviene mantener una tabla propia de claves aplicadas.
Primero dry-run, y déjalo para siempre
El agente produce el conjunto exacto de escrituras que pretende hacer, el sistema las presenta como diff y no se aplica nada. Dos semanas de eso contra datos reales enseñan dónde se equivoca el agente.
El modo se queda después del lanzamiento. Sirve como prueba de regresión cuando cambia el prompt y para incorporar a un equipo comercial escéptico.
Decide qué acciones aprueba una persona
El criterio útil es la reversibilidad. Una nota añadida, una actividad registrada o una etiqueta sugerida pasan directas. Cambios de etapa, reasignación, fusiones, borrados y cualquier acción que dispare un mensaje hacia fuera necesitan aprobación.
La guía de OWASP sobre excessive agency apunta igual: reducir funcionalidad, reducir permisos y exigir aprobación antes de las acciones con consecuencias. La aprobación necesita interfaz real. Una cola dentro del CRM funciona; un mensaje de Slack sin dueño es otra versión de la brecha que mata buenos leads entre marketing y ventas.
El log de auditoría es el entregable
Se registra el disparador, el contexto recuperado, la salida del modelo, la llamada a la herramienta, la clave de idempotencia y la decisión humana. El almacén es de solo anexado, fuera del alcance de la credencial del agente.
Ese log responde a la única pregunta que importa tras un incidente: qué cambió, cuándo y con qué entrada. Es también la base probatoria de las obligaciones de registro que llegan con el calendario del Reglamento Europeo de IA. La taxonomía que NIST publicó en 2025 es directa: estas mitigaciones siguen siendo empíricas. Revertir no es prevenir, pero es lo que hay.
Preguntas frecuentes
¿Se puede prevenir del todo la inyección de prompts?
No. La taxonomía NIST AI 100-2e2025, de marzo de 2025, señala que las mitigaciones frente a ataques de aprendizaje automático adversario son sobre todo empíricas y pueden fallar ante técnicas nuevas. La inyección se trata como restricción permanente de diseño.
¿Cuál es el montaje seguro mínimo?
Una credencial de integración limitada a cuatro o cinco campos, tres o cuatro herramientas estrechas, claves de idempotencia en cada escritura, dry-run por defecto y aprobación humana en lo irreversible. Todo lo demás, incluida la elección de modelo, pesa menos.
¿El agente escribe directo o propone cambios?
Primero propone. Se mantiene en dry-run varias semanas, se mide con qué frecuencia una persona acepta la propuesta sin editarla y se promueven solo las acciones que superan un umbral fijado de antemano. La promoción es por tipo de acción, nunca para el agente entero.
¿Qué modelo conviene usar?
El más barato de evaluar contra tu propio conjunto de tareas. El modelo afecta a la frecuencia con la que el agente propone algo útil. No afecta a lo que puede hacer un agente comprometido, igual que en cualquier discusión sobre recuperación, evaluación y coste en producción.
Construye en este orden: alcance de la credencial, idempotencia, dry-run, puertas de aprobación y log. Invertirlo produce una demo que no se puede auditar. Es la trampa de juzgar las funciones de IA de un CRM por la demo, y la razón por la que la decisión de construir, comprar o envolver va primero. Dentro de seis meses habrá datos para saber qué acciones se ganaron autonomía. Hasta entonces, el botón de lo irreversible lo pulsa una persona.
