Cómo dar acceso a un agente de IA sin renunciar al control

El camino rápido — darle al agente acceso de administrador y dejar los detalles para después — crea exactamente el radio de impacto que quema a los equipos. Este es el modelo por capas que lo evita, comprobado línea por línea contra lo que de verdad está en producción.

La forma más rápida de conectar un agente de IA a un sistema real es darle el mismo acceso que le darías a una persona recién contratada el primer día: administrador total, todas las herramientas, los detalles para más tarde. Acotar el acceso como es debido lleva tiempo: alguien tiene que decidir qué herramientas puede tocar el agente, qué datos puede leer y qué puede hacer sin preguntar primero. En un equipo pequeño que ya va justo de capacidad, nadie quiere ser quien frene eso. Así que lo predeterminado pasa a ser «dale acceso y ya», y todo el mundo sigue con lo siguiente.

Ese instinto está mal, y la razón no tiene nada que ver con si el agente parece de fiar hoy. Se trata de lo que ocurre el día en que no lo es. Un agente con el alcance de un administrador que comete un error rutinario, recibe una instrucción envenenada enterrada en un documento que le pidieron leer, o simplemente está seguro y equivocado sobre lo que hará una llamada a una herramienta, tiene ahora el alcance de un administrador. El fallo no es una mala respuesta de chatbot que cualquiera puede encogerse de hombros: es el radio de impacto de una cuenta de administrador comprometida, salvo que puede actuar a velocidad de máquina, en cada sistema que toca, sin que nadie esté mirando en tiempo real para detenerlo antes de que el daño se acumule.

La pila que de verdad contiene el radio de impacto

Un buen diseño de acceso para un agente de IA no es un interruptor que se pulsa. Son seis decisiones separadas, apiladas unas sobre otras, en las que cada capa existe para detener una forma concreta en la que el primer error se convierte en uno mucho mayor. Saltarse una capa no simplifica nada: solo mueve el punto de fallo a un sitio menos visible.

Ninguna de estas seis capas es exótica. Cada una cierra un hueco que la capa de arriba deja abierto de par en par: la identidad por sí sola no detiene un acceso a herramientas demasiado amplio, y una lista de herramientas permitidas por sí sola no detiene una acción silenciosa e irreversible. Solo funcionan apiladas.

Identidad: un inicio de sesión, no uno en la sombra

Se empieza por la identidad porque todo lo que está encima hereda de ella. Si el acceso de un agente está ligado a un inicio de sesión del que TI no sabe que existe, ninguna de las capas posteriores importa: no puedes revocar una concesión de la que nunca supiste. El plan Enterprise de FabricLoop conecta el espacio de trabajo con el proveedor de identidad de la organización mediante SSO y SAML, el mismo mecanismo que ya controla el inicio de sesión del correo y del resto del software de la empresa. Eso importa en concreto para el acceso de los agentes, porque las conexiones de IA y el acceso de colaboración ordinario pasan por una sola historia de identidad, no por dos. Cuando TI desaprovisiona a alguien en el proveedor de identidad, esa única acción elimina su acceso a FabricLoop y, con él, cualquier conexión MCP ligada a su inicio de sesión, en lugar de dejar atrás una credencial de agente huérfana que nadie recuerda limpiar.

Una concesión por persona, en las dos direcciones

Las conexiones de IA de FabricLoop funcionan en dos direcciones, y el mismo principio —ninguna credencial compartida para todo el equipo— se aplica a ambas.

Entrante es cuando una herramienta externa como Cursor, Claude o ChatGPT se conecta a FabricLoop como cliente MCP, para poder leer o escribir tareas, notas y mensajes con los permisos reales de alguien. Las propias instrucciones de configuración de FabricLoop dejan claro que esto es un proceso por persona: cada persona abre la pantalla de consentimiento en app.fabricloop.com/oauth/consent, elige el espacio de trabajo y aprueba los alcances de herramientas concretos que obtiene ese cliente, no un interruptor de todo el espacio que un administrador pulsa una vez para todos. La orientación a los equipos nombra directamente el modo de fallo que esto está hecho para evitar: no compartas el token de acceso de una persona con todo el equipo, porque cada persona debe completar su propio consentimiento. El resultado es una lista de clientes conectados visible por persona y revocable por persona, no un token de acceso enterrado en un archivo de configuración que sobrevive al motivo por el que se creó.

Saliente es el caso espejo: FabricLoop se conecta hacia una aplicación de terceros de su propio catálogo MCP, como un rastreador de proyectos o una herramienta de calendario. Aquí la división es deliberada. Un administrador habilita la aplicación para todo el espacio de trabajo —una decisión sobre si la herramienta puede existir en la organización— y después cada persona que quiere usarla conecta su propia cuenta individual. Que un administrador pulse ese interruptor no entrega la identidad de cada empleado a la aplicación; solo hace que la opción esté disponible, y cada persona sigue teniendo que autenticarse como sí misma antes de que la conexión haga nada.

Alcance: solo lectura, o una lista permitida — no todo o nada

La identidad responde quién. Las concesiones por persona responden de quién es la cuenta. Ninguna de las dos responde la pregunta que de verdad determina el tamaño de un error: qué puede hacer la conexión una vez que está activa. Ese es el trabajo de la tercera capa.

En la pantalla de detalle de cualquier aplicación conectada, un administrador puede fijar un nombre visible, activar el modo de solo lectura y elegir una política de herramientas: o todas las herramientas disponibles, o una lista permitida concreta. Esa es la diferencia entre «este agente puede leer nuestro tablero de tareas» y «este agente puede leer nuestro tablero de tareas y también borrar registros, reasignar responsables y publicar en cada canal». La mayoría de las conexiones no necesitan la segunda versión, y la mayoría de las historias en las que el acceso de un agente sale mal del modo que la gente teme empiezan con una conexión a la que se le concedió cada herramienta por defecto, porque nadie pensó en marcar la casilla que lo limita.

La página de seguridad de FabricLoop describe las concesiones resultantes como «acotadas» y, de forma explícita, como «no un acceso permanente e invisible»: auditadas y revocables, el mismo lenguaje que la empresa usa en su página que explica la Legibilidad, la idea de que el acceso de la IA debe ser algo que se pueda nombrar e inspeccionar, en lugar de un saber informal sobre qué token viejo de bot sigue funcionando.

Comportamiento en tiempo de ejecución: el agente redacta, una persona envía

Todo lo que está por encima de esta capa controla a qué puede llegar un agente. Esta controla qué se le permite hacer una vez que llega, y es la capa que la mayoría de los equipos se saltan, porque es la que se siente más lenta.

El asistente integrado de FabricLoop, Loop, está construido en torno a una restricción que la empresa enuncia con claridad en su propia documentación de producto: «Loop redacta; tú envías. No publica en un canal ni avisa a nadie por su cuenta.» Pídele que resuma un hilo y resume. Pídele que escriba una actualización y escribe un borrador, y una persona sigue teniendo que revisarlo y enviarlo antes de que nadie más lo vea. El mismo patrón vale para los agentes que viven en un canal como compañeros de equipo: cuando uno de esos agentes espera una decisión de una persona, no adivina y sigue. Aparece bajo «Esperando tu respuesta» en la pestaña Aplicaciones y agentes de ese canal: exactamente la superficie que el equipo ya revisa, no una consola aparte de la que nadie se acuerda.

Esa es la forma práctica de lo que la literatura de frameworks de agentes llama un patrón ask_human / resume: el agente se detiene en el punto en el que hace falta juicio, pregunta y solo continúa cuando una persona responde. FabricLoop enmarca la idea de fondo como la Tasa de intervención humana: no «con qué frecuencia el agente necesita a un humano», tratado como un fallo que hay que eliminar con ingeniería, sino un número que cada equipo que opera agentes debería medir de verdad y para el que debería diseñar, en lugar de descubrirlo por primera vez durante un incidente.

El cortacircuitos: un límite de gasto que de verdad detiene las ejecuciones

El control de acceso no trata solo de lo que un agente puede leer o cambiar. También trata de lo que puede costar, y un agente desbocado no necesita tocar nada sensible para hacer daño real si está haciendo llamadas caras al modelo en un bucle que nadie vigila.

Los administradores de los planes de pago de FabricLoop fijan un límite de gasto mensual para el uso de agentes en Uso & facturación, y pueden activar una parada dura que pausa automáticamente el trabajo nuevo de los agentes en cuanto el gasto llega a esa cifra. Es un cortacircuitos de verdad, no un panel de monitorización: la diferencia entre notar que la factura fue alta a final de mes y que las nuevas ejecuciones de agentes se detengan solas en el momento en que cruzan el número que alguien fijó. Los espacios de trabajo gratuitos no tienen un límite en dólares, porque no hay gasto de producción que topar: funcionan con créditos de prueba incluidos, que son un límite de alcance por sí mismos, solo que se aplica de otra forma. En un plan de pago, subir el límite es la única forma de reanudar una vez que se dispara una parada dura, y esa es exactamente la fricción que quieres en ese momento: alguien tiene que decidir de forma activa gastar más, en lugar de que el sistema vuelva en silencio a lo ilimitado.

Auditoría y revocación: una persona, o todos, de una vez

La última capa asume que las cinco primeras acabarán fallando en algún sitio, para alguien, y pregunta qué ocurre después.

FabricLoop separa dos tipos de revocación, y la distinción importa. «Revocar mi conexión» está disponible para cualquier persona y desconecta de inmediato solo el acceso de esa persona: la herramienta deja de funcionar para ella sin tocar a nadie más del equipo que también esté conectado. «Desactivar la aplicación para el espacio de trabajo» es solo para administradores y es la acción más amplia: archiva la aplicación por completo y revoca de una vez todas las conexiones hacia ella, para el caso en que el problema no es la cuenta de una persona sino la aplicación misma. La misma división existe en el lado entrante, donde cualquier persona puede revocar al instante un cliente MCP que conectó, desde Ajustes → IA / MCP.

Nada de eso importa sin visibilidad de lo que ocurrió antes de que alguien decidiera cortar. Los registros de auditoría Enterprise de FabricLoop no son solo un historial de inicios de sesión: la empresa los describe como cobertura de la actividad de administradores y de agentes, y sus propios materiales sobre el concepto de Legibilidad nombran de forma específica los «eventos de auditoría MCP» como algo que los equipos de seguridad pueden revisar, no solo inferir del contexto. Esa es la diferencia entre un equipo de seguridad que pregunta «¿alguien tocó esto?» y obtiene una respuesta real, y reconstruir una cronología a partir de mensajes viejos y del recuerdo de alguien sobre lo que un agente parecía estar haciendo aquella tarde.

Lo que FabricLoop dice que todavía no es verdad

Cada afirmación de arriba es algo que FabricLoop ha puesto de verdad en producción. Merece la pena ser igual de claro sobre lo que no se ha publicado, porque una empresa que solo cuenta la primera mitad te pide que confíes en ella a ciegas, y la fe no es lo que significa una postura de seguridad legible.

La propia página de seguridad de FabricLoop enumera lo que es verdad hoy y, después, una sección aparte, titulada con claridad «Todavía no está en marcha», que nombra tres huecos concretos: la certificación SOC 2 o ISO 27001, las pruebas de penetración de terceros y el aprovisionamiento SCIM. El encuadre de la página es inusualmente directo para una página de seguridad de un proveedor: en lugar de listar cada certificación que tienen otros proveedores, dice aquí está exactamente lo que es verdad ahora mismo, y lo que todavía no está en marcha, porque la empresa prefiere decirlo con claridad antes que dejar que un cliente lo descubra más tarde.

Para un equipo que sopesa si conectar un agente a datos reales de la empresa, esos no son riesgos vagos: son tres puntos nombrados y comprobables que puedes plantear en una revisión de seguridad, seguir y retomar antes de la renovación. Una lista declarada de huecos vale más que una garantía vaga de que todo está bien, precisamente porque se puede comprobar. Es el mismo argumento que hay detrás de la Legibilidad como concepto: un acceso y una postura que puedes nombrar y verificar ganan a un acceso y una postura que simplemente te piden que creas.