Agentic Fabriq: funciones, gateway MCP y precios (2026)

Agentic Fabriq es una plataforma de identidad y permisos para agentes de IA. Se sitúa entre el agente y las herramientas, incorpora la identidad del usuario a cada solicitud, aplica políticas de acceso, administra credenciales y registra lo ocurrido.

Su función es distinta de la de un framework: no decide cómo razona el agente ni qué tarea debe realizar. Controla a qué puede acceder y qué puede hacer después de elegir una acción.

La empresa se fundó en 2025 y participó en la promoción de invierno de 2026 de Y Combinator. Esta guía describe el producto en septiembre de 2026: funcionamiento, papel de MCP, costes y casos donde encaja.

Qué problema resuelve

Imagina un agente de soporte que consulta el expediente de un cliente, comprueba un pedido en Stripe y envía un seguimiento mediante Gmail. Habilitar esas herramientas plantea varias preguntas:

• ¿Qué agente hizo la solicitud?
• ¿En nombre de qué usuario actuaba?
• ¿Tiene ese usuario permiso para esa acción concreta?
• ¿Dónde se guardan sus tokens OAuth?
• ¿Se puede revocar el acceso sin volver a desplegar el agente?
• ¿Existe un registro fiable de llamadas permitidas, rechazadas y sujetas a aprobación?

Una cuenta de servicio compartida responde a pocas de ellas: todos reciben la misma autoridad, las credenciales permanecen en la infraestructura y resulta difícil atribuir acciones. Una biblioteca OAuth resuelve el flujo de acceso, pero no las políticas del agente ni una auditoría unificada.

Según la documentación, Fabriq asocia cada petición con un agente y un usuario, comprueba esa pareja frente a la política vigente y solo después la envía a la herramienta.

Cómo funciona

El flujo habitual tiene cinco partes:

1. Registrar la aplicación o el agente. Se define su identidad y el máximo alcance que puede solicitar.
2. Conectar las cuentas de cada usuario. El usuario completa un consentimiento OAuth alojado para Gmail, Slack, GitHub u otros servicios; Fabriq guarda las credenciales en su bóveda.
3. Emitir un token breve limitado al usuario. El backend usa el identificador del usuario en tu aplicación; el secreto de Fabriq permanece en el servidor.
4. Llamar a través del gateway. Con el SDK de Python o un único endpoint MCP, el agente descubre y utiliza solo las herramientas disponibles para ese usuario.
5. Aplicar la política y registrar. Fabriq verifica la acción, añade la credencial del proveedor en el servidor, reenvía la llamada permitida y escribe el resultado en el registro de auditoría.

El límite decisivo está en el quinto paso. Un prompt del sistema puede pedir que se respete una política, pero una instrucción no constituye un control de seguridad. Fabriq comprueba los permisos fuera del modelo, justo al llamar a las herramientas.

Funciones principales

Identidad del agente y del usuario

Cada petición representa a un agente que actúa para un usuario concreto. El permiso efectivo es la intersección entre las facultades del agente y las que ya posee la persona. Si el agente puede emitir reembolsos pero el usuario no, la operación sigue bloqueada.

En agentes internos compartidos, los permisos pueden variar por organización, equipo, miembro y acción. Un mismo despliegue puede ofrecer solo lectura a una persona y escritura limitada a otra.

Gateway MCP con políticas

Las herramientas conectadas se exponen mediante un único endpoint Model Context Protocol sujeto a políticas. La lista se construye para el usuario actual; una herramienta prohibida puede ocultarse en lugar de rechazarse únicamente después de que el modelo la elija.

El catálogo de integraciones incluye Google Workspace, Microsoft 365, mensajería, herramientas de desarrollo, CRM, soporte y datos. También admite servicios OpenAPI, servidores MCP existentes y conexiones Postgres protegidas.

Bóveda de credenciales e intermediación OAuth

Los usuarios autorizan sus propias cuentas. Los tokens de acceso y renovación permanecen en la bóveda de Fabriq y se incorporan al reenviar una llamada, sin devolverse al agente ni guardarse en la base de datos del producto. La plataforma también gestiona renovación y revocación.

Es útil en productos para clientes: cada cliente puede conectar su Gmail o Slack sin que el desarrollador mantenga un almacén de tokens para cada proveedor.

Políticas y aprobaciones

Fabriq deniega por defecto y permite conceder acceso hasta el nivel de acciones individuales. Consulta la política en cada solicitud, de modo que un cambio afecta a la siguiente llamada sin redesplegar. El producto empresarial también puede enviar operaciones sensibles a flujos de aprobación.

Auditoría

Cada llamada puede registrar usuario, agente, herramienta, acción y veredicto. El equipo de seguridad obtiene un historial común entre servicios sin reconstruirlo a partir de registros separados.

Una auditoría no garantiza por sí sola el cumplimiento normativo, pero aporta atribución y pruebas para investigar incidentes y aplicar controles propios.

¿Es un servidor MCP?

Sí, proporciona un endpoint MCP, aunque describirlo solo así omite su valor principal.

Puede situarse entre cualquier entorno compatible con MCP y múltiples herramientas, o incorporar un servidor MCP existente al mismo límite de identidad y políticas. MCP es la interfaz de conexión; el producto es la gobernanza.

Casos de desarrollo y empresa

Productos cuyos agentes actúan para clientes

En el modelo de desarrollo, tu aplicación conserva un ID y un secreto de Fabriq. Cada cliente conecta sus cuentas externas dentro del producto; las llamadas se limitan al identificador de usuario enviado. El cliente no necesita una cuenta independiente de Fabriq.

Encaja en productos de IA que necesitan acceso autorizado por el cliente a correo, calendarios, documentos, mensajería y otros servicios SaaS.

Agentes que actúan para empleados

En el modelo empresarial, los empleados conectan cuentas desde el espacio de Fabriq. Los administradores gestionan permisos de agentes compartidos, conectan al proveedor de identidad de la organización y revisan la actividad de forma centralizada.

Encaja en asistentes internos, agentes de soporte u operaciones y agentes de programación que deben respetar los límites de acceso del empleado.

Precios

Estos eran los planes de desarrollo publicados el 11 de septiembre de 2026:

En los planes de desarrollo de pago, el exceso figura a $2 por cada 10,000 llamadas. No se cuentan solo invocaciones de herramientas: la autenticación, el acceso a herramientas y las solicitudes de credenciales también pueden consumir llamadas. Modela el flujo completo y confirma las condiciones actuales en la página oficial de precios.

Cuándo encaja

Conviene evaluarlo si:

• El agente actúa para muchos usuarios diferentes.
• Los usuarios conectan herramientas empresariales mediante OAuth.
• Las claves compartidas o cuentas de servicio amplias ya no son aceptables.
• Los permisos cambian según agente, usuario y acción.
• Seguridad necesita atribución, revocación y auditoría centralizadas.
• Varios entornos de agentes deben reutilizar las mismas integraciones controladas.

Puede resultar innecesario para un prototipo que solo llama a APIs públicas o usa una única credencial propia muy restringida. Tampoco sustituye la orquestación, las evaluaciones, la seguridad de prompts ni la revisión humana de decisiones con gran impacto.

Qué evaluar antes de adoptarlo

Al formar parte de la ruta crítica de las llamadas, debe evaluarse como infraestructura de identidad:

1. Cobertura: ¿Incluye exactamente las acciones y permisos necesarios?
2. Modelo de políticas: ¿Expresa con suficiente precisión los límites de recursos y aprobaciones?
3. Fallos: ¿Qué ocurre si no están disponibles el gateway, el proveedor de identidad o el servicio final?
4. Credenciales y datos: ¿La nube administrada cumple los requisitos de seguridad y residencia, o se necesita la opción personalizada de alojamiento propio?
5. Coste real: ¿Cuántas llamadas genera una tarea completa del usuario?
6. Observabilidad: ¿Se pueden exportar las pruebas necesarias para incidentes y cumplimiento?

Conclusión

Cuando una demostración de IA se convierte en un sistema de producción multiusuario, el agente necesita capacidades reales sin superar la autoridad de la persona a la que representa.

Fabriq destaca al permitir herramientas reales sin entregar credenciales directamente ni confiar en prompts para comprobar permisos. Para equipos con ese problema, merece evaluar la combinación de identidad por usuario, gateway MCP gobernado, intermediación de credenciales y auditoría centralizada.

A

Agentic Fabriq

Identidad y permisos para agentes mediante una pasarela MCP gobernada