Respuesta directa
En pocas palabras
Para limitar un agente de IA, ofrece únicamente herramientas necesarias para su caso de uso, divide lectura, borrador, escritura, envío y administración en acciones distintas, y valida cada llamada fuera del modelo. La política debe comprobar identidad del usuario y del workload, organización, recurso, verbo, finalidad, argumentos, vigencia y aprobación. Las acciones irreversibles o materiales requieren confirmación humana informada; los límites de tasa, costo, volumen y destino reducen el impacto; y las pruebas deben demostrar tanto lo permitido como lo denegado.
Separa capacidad, permiso, autonomía y acción antes de conectar una herramienta
Una capacidad describe lo que una herramienta puede hacer. El permiso delimita qué identidad puede usarla y sobre qué recurso. La autonomía determina si el sistema propone, prepara o ejecuta sin otra confirmación. La acción es la solicitud concreta con argumentos, objeto, destino y momento. Mezclar estas capas crea agencia excesiva: una función legítima termina disponible para más personas, más datos o más efectos de los necesarios.
Define el recorrido desde el efecto final. Leer un registro, redactar un correo, guardar un borrador, enviarlo, cambiar una etapa, exportar contactos y administrar usuarios no son variantes de una misma operación. Tienen consecuencias y autoridades distintas. OWASP describe la agencia excesiva como una combinación de funcionalidad, permisos o autonomía excesivos. Reducir solo el prompt no corrige una credencial poderosa ni una extensión que también puede borrar, enviar o ejecutar código.
Construye un registro de herramientas y efectos reales
Registra cada herramienta con identificador estable, versión, propietario, proveedor, ambientes, identidades consumidoras, datos que lee, objetos que modifica, destinos de red, secretos requeridos, costo posible, límites, dependencia y ruta de desactivación. Incluye funciones internas, conectores, plugins, MCP servers, jobs, webhooks, navegadores, intérpretes y delegaciones hacia otros agentes. Una herramienta fuera del catálogo sigue ampliando la superficie aunque nadie la muestre en la interfaz.
Describe el efecto observado, no el nombre comercial. Una función llamada buscar puede consultar una fuente, recorrer Internet, descargar un archivo o ejecutar una consulta arbitraria. Verifica el contrato y la implementación. El inventario debe responder qué ocurriría si una entrada maliciosa selecciona la herramienta, modifica sus argumentos, repite la llamada o encadena el resultado con otra capacidad. Relaciónala con el caso de uso autorizado y elimina herramientas de pruebas o versiones antiguas que todavía puedan invocarse.
Prefiere herramientas estrechas frente a interfaces abiertas
Una herramienta específica expresa una intención limitada: obtener productos activos de una organización, crear un borrador de propuesta o registrar una nota con longitud máxima. Una interfaz abierta como ejecutar shell, consultar SQL libre, hacer fetch de cualquier URL o llamar cualquier endpoint multiplica rutas no previstas. Si el caso necesita una operación concreta, construye esa operación y no expongas un intérprete general al planificador.
La restricción debe existir en el código y en el servicio destino. Una descripción que dice solo lectura no impide que la credencial escriba. Separa endpoints, cuentas, roles y funciones para que el camino técnico no incluya verbos innecesarios. Fija versión y origen de la herramienta; rechaza alias ambiguos, nombres parecidos y cambios de esquema no aprobados. Si una capacidad abierta es indispensable para mantenimiento, muévela a otro proceso, identidad y entorno con aprobación especializada.
| Criterio | Diseño limitado | Riesgo del diseño amplio |
|---|---|---|
| Consultar catálogo | Filtro por organización y campos permitidos | SQL libre sobre la base completa |
| Guardar un documento | Crear borrador en carpeta autorizada | Acceso general al sistema de archivos |
| Consultar una fuente | Conector con dominio y ruta permitidos | Fetch de cualquier URL con red interna |
| Ejecutar una tarea | Job versionado con parámetros tipados | Shell o código arbitrario en producción |
Divide observar, redactar, guardar, enviar, modificar y administrar
Crea una matriz por acción, no un rol genérico llamado agente. Para cada verbo define actor, recurso, organización, datos, finalidad, efecto, reversibilidad, aprobación, límite y evidencia. Observar y recomendar suelen admitir controles ligeros. Guardar modifica un sistema de registro. Enviar produce un efecto externo. Administrar puede ampliar permisos o crear credenciales. El nivel de revisión aumenta con autoridad, alcance, irreversibilidad y dificultad de detectar el error.
No permitas que una secuencia convierta varias capacidades moderadas en una acción material sin gate. Leer un CRM, redactar texto y llamar un conector de correo equivale a preparar y enviar aunque ninguna herramienta se llame venta automática. Evalúa el recorrido completo y los efectos acumulados. Declara estados seguros: borrador pendiente, propuesta sin precio confirmado, acción bloqueada, aprobación vencida o destino fuera de alcance. El fallback no debe usar una identidad más poderosa para mantener disponibilidad.
Vincula cada ejecución con usuario, workload, organización y propósito
Una llamada debe conservar dos identidades: la persona o proceso que originó la solicitud y el workload que la ejecuta. Añade organización, sesión, caso de uso, recurso, acción, release y propósito. No uses una cuenta global para representar a todos los usuarios. NIST SP 800-207A desplaza la confianza implícita de la red hacia identidades de aplicaciones y servicios con políticas granulares. Estar dentro de la nube o provenir de otro agente no concede autoridad.
En un sistema multi-tenant, la organización es una frontera obligatoria en cada consulta y mutación. No aceptes un tenant_id elegido por el modelo como prueba de acceso. Derívalo de la sesión o del contexto autorizado, y confirma que el objeto pertenece a esa organización. Cuando una persona delega, limita la delegación a acciones, recursos y tiempo concretos. Un agente hijo no hereda automáticamente todos los privilegios del agente coordinador ni de la cuenta que creó el flujo.
Autoriza en un punto de aplicación fuera del modelo
Coloca un policy enforcement point entre el plan del agente y el sistema que produce el efecto. Recibe una solicitud estructurada y comprueba identidad, organización, recurso, acción, propósito, ambiente, versión, permisos, estado de sesión, límites y aprobación. La decisión permite, deniega o exige un paso adicional. El servicio destino vuelve a validar; no confía en que el orquestador ya revisó. Esta mediación completa evita que una ruta secundaria salte la política.
La política debe ser determinista y versionada. Conserva identificador de regla y resultado sin registrar secretos ni texto sensible innecesario. Deniega por defecto campos, acciones y herramientas desconocidos. Si el motor de políticas no está disponible, el comportamiento seguro para una acción material es bloquear o degradar a borrador, no continuar sin control. Separa quien desarrolla la herramienta, quien aprueba la política y quien puede habilitarla en producción cuando la materialidad lo justifique.
Valida intención, argumentos y estado justo antes de ejecutar
Define esquemas cerrados con tipos, longitud, formatos, enumeraciones y campos obligatorios. Rechaza propiedades adicionales, URLs fuera de allowlist, rutas relativas peligrosas, consultas libres, identificadores que no pertenecen al usuario y contenido que cambia la semántica de una operación. Normaliza antes de comparar. Una llamada sintácticamente válida todavía puede ser incorrecta si el destino, el monto, la moneda o la finalidad no corresponden al recorrido aprobado.
Vuelve a comprobar autorización y estado en el momento de uso. Entre planear y ejecutar pueden cambiar permisos, etapa, owner, precio, sesión o aprobación. Evita time-of-check to time-of-use: el resultado anterior no abre una ventana indefinida. Usa idempotency keys en mutaciones, precondiciones de versión y protección contra replays. Devuelve errores claros al orquestador, pero no datos que ayuden a enumerar recursos de otra organización o reconstruir una credencial.
Pide aprobación informada para acciones materiales o irreversibles
La persona que aprueba necesita ver acción, destino, objeto, cambios, datos compartidos, costo, consecuencia y posibilidad de reversión. No muestres solo un botón continuar junto a un resumen generado por el mismo modelo. Presenta valores procedentes de sistemas autorizados y marca faltantes o diferencias. La aprobación corresponde a una operación concreta y vence si cambian argumentos, identidad, precio, moneda, audiencia o versión relevante.
Exige confirmación para enviar externamente, modificar registros materiales, conceder acceso, exportar datos, borrar, ejecutar código, comprometer condiciones comerciales o elevar privilegios. La revisión no es significativa cuando el volumen impide leer, la interfaz oculta el efecto o aprobar se vuelve rutinario. Reduce lote, añade muestreo y doble control, o conserva el proceso manual. La persona debe poder rechazar, editar, pedir contexto y detener el recorrido sin perder el trabajo preparado.
Acota tasa, volumen, costo, tiempo, concurrencia y propagación
Incluso una acción autorizada puede causar daño por repetición o escala. Define presupuestos por usuario, organización, herramienta, sesión y periodo: número de llamadas, registros, destinatarios, bytes, tokens, costo, tiempo, profundidad de delegación y reintentos. El límite se aplica antes del efecto y no puede ampliarse desde el prompt. Al alcanzarlo, pausa, degrada o pide nueva autorización; no dividas silenciosamente el lote para eludir la cuota.
Diseña reversibilidad donde sea posible. Prefiere borradores, soft delete, versiones, transacciones, canary y colas con cancelación frente a efectos inmediatos. Registra un identificador idempotente para que un timeout no duplique envíos o cambios. Los circuit breakers detienen secuencias anómalas; los límites de egress evitan que una lectura legítima se encadene con una transferencia externa. Un presupuesto reduce blast radius, pero no convierte una acción prohibida en aceptable.
Impide que delegación, memoria o contexto hereden privilegios
Cada agente o worker usa identidad propia y recibe una tarea estrecha. El coordinador transmite intención firmada o contexto mínimo, no su sesión completa. El receptor autentica al emisor y vuelve a autorizar al usuario originador. No confíes en una etiqueta como agente interno, administrador auxiliar o verificado. En cadenas multiagente, registra quién pidió, quién delegó, quién decidió y quién produjo el efecto.
Separa memoria por organización, usuario, caso y nivel de privilegio. No guardes tokens, secretos ni resultados sensibles para que otro recorrido los reutilice. Limpia el contexto al cambiar de identidad o propósito. Una aprobación anterior no se conserva como una instrucción general. OWASP identifica el abuso de identidad y privilegios cuando las cadenas de delegación, credenciales heredadas o memoria permiten elevar acceso. La defensa combina aislamiento, permisos por tarea, nueva autorización y revocación automática.
Aísla ejecución y controla destinos de red y datos
Las herramientas que procesan archivos, HTML, código, documentos o contenido recuperado operan en un sandbox proporcional al riesgo. Limita filesystem, procesos, red, metadatos de nube, variables, dispositivos, tiempo, memoria y paquetes. Monta solo los datos necesarios y destruye el entorno al terminar. No conectes un navegador autenticado o un intérprete de código directamente con producción si un recorrido aislado puede resolver la tarea.
Aplica egress allowlists por herramienta y finalidad. Resuelve DNS y redirecciones bajo política, bloquea rangos internos y verifica el destino final. Clasifica la salida antes de enviarla a otro sistema. Una instrucción incrustada en una web, correo o documento no puede cambiar permisos ni autorizar otra herramienta. Separa datos de instrucciones y etiqueta procedencia para que el planificador sepa qué contenido es evidencia, qué es entrada no confiable y qué regla no puede sobrescribirse.
Registra decisiones y secuencias sin copiar secretos ni datos innecesarios
Conserva correlación, tiempo, usuario, workload, organización, herramienta, versión, recurso, verbo, política, decisión, aprobación, límites consumidos, resultado y error. Para argumentos sensibles, registra campos permitidos, hashes o referencias según necesidad; no vuelques prompts completos, tokens o documentos por comodidad. El log debe permitir reconstruir qué acción se intentó y por qué fue permitida o negada sin convertirse en otra fuente de exposición.
Alerta por herramientas desconocidas, denegaciones repetidas, cambio de organización, elevación de privilegio, secuencias inusuales, volumen, egress nuevo, uso fuera de horario, replays y acciones después de revocación. Una lectura de base seguida por transferencia externa merece atención aunque ambas funciones existan. Define quién responde, qué evidencia preserva y cómo pausa. La ausencia de alertas no demuestra seguridad: mide cobertura, latencia y calidad de detección con ejercicios controlados.
Prueba permisos negativos, abuso de secuencias y capacidad de detener
Las pruebas positivas demuestran que el recorrido autorizado funciona. Las negativas demuestran que otro usuario, organización, acción, herramienta, destino, moneda, precio o estado no funciona. Incluye prompt injection directa e indirecta, argumentos extra, IDs ajenos, aprobación vencida, permiso revocado, replay, doble ejecución, tool alias, esquema nuevo, lote excesivo, costo agotado, memoria cruzada y delegación hacia un agente más poderoso. Comprueba el rechazo en el destino, no solo en la interfaz.
Ensaya pausa, revocación y recuperación. El kill switch debe bloquear nuevas acciones y permitir preservar evidencia y continuar manualmente. Verifica sesiones, colas, jobs y credenciales ya emitidas; deshabilitar el nombre de una herramienta no siempre detiene trabajo en curso. Prueba rollback de política y versión sin reabrir privilegios amplios. Registra esperado, observado, versión, identidad, evidencia, severidad y responsable. Un test anterior a un cambio de herramienta o permiso deja de cubrir la versión actual.
Gobierna el ciclo de vida y conserva los límites públicos de Cerravi
Aprueba una herramienta con caso de uso, versión, owner, identidades, política, pruebas, monitoreo y fecha de revisión. Reabre la decisión cuando cambian esquema, proveedor, modelo, datos, permiso, destino, autonomía o volumen. Retira funciones sin uso, revoca identidades y secretos, cancela jobs y verifica que la versión antigua ya no responda. Las excepciones tienen alcance, control compensatorio, vencimiento y cierre técnico; una renovación repetida exige rediseño.
En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana. Los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios conocidos; si falta un importe, se muestra para revisión y no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. La actividad de Buyer Room aporta señales, pero no confirma identidad, aceptación, firma, pago ni intención. Forecast usa reglas transparentes del CRM; no es un modelo predictivo entrenado o calibrado y no garantiza cierres. Cualquier automatización que una empresa conecte alrededor de Cerravi debe evaluar el recorrido completo y no atribuirle capacidades que el producto público no declara.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿El system prompt puede limitar los permisos de un agente de IA?
Puede orientar comportamiento, pero no es un control de autorización. El sistema debe limitar herramientas y credenciales, validar identidad, organización, recurso y acción fuera del modelo, y volver a comprobar permisos en el servicio que produce el efecto.
¿Qué acciones de un agente requieren aprobación humana?
Las que producen efectos materiales, externos, privilegiados o difíciles de revertir: enviar, borrar, exportar, conceder acceso, ejecutar código, modificar condiciones comerciales o elevar permisos. La aprobación debe mostrar acción, destino, datos, costo y consecuencia, y quedar vinculada a argumentos concretos.
¿Qué significa aplicar mínimo privilegio a una herramienta de IA?
Significa ofrecer solo la función necesaria, usar una identidad separada y limitar recursos, verbos, organización, finalidad, duración y destino. También exige probar que las operaciones prohibidas fallan; una descripción de solo lectura no basta si la credencial todavía puede escribir.
¿Cómo se evita que un agente acceda a datos de otra empresa?
Deriva la organización desde la sesión autorizada, valida que cada objeto le pertenece y aplica el filtro también en el servicio destino. No aceptes un tenant_id elegido por el modelo ni una identidad global con acceso a todas las organizaciones.
¿Qué debe registrar el log de una llamada a herramienta?
Identidad originadora y ejecutora, organización, herramienta y versión, recurso, acción, política, decisión, aprobación, límites y resultado. Los secretos y datos sensibles deben redactarse o sustituirse por referencias; el log explica la decisión sin convertirse en una copia del contenido.