La mayoría de los agentes de AI empresariales hoy analizan, pero no ejecutan. Resumen documentos, detectan insights y redactan respuestas. No cierran tickets de soporte, no actualizan Salesforce ni disparan despliegues. El ROI sigue siendo incremental. La arquitectura que resuelve esto es un runtime MCP: una capa de ejecución segura que gestiona autorización, credenciales y llamadas a herramientas en nombre de cada usuario.
La transformación real ocurre cuando los agentes toman acciones, cuando los empleados dirigen el trabajo en lugar de hacerlo. Pero lograr que los agentes ejecuten de forma segura en sistemas empresariales es justo donde todo se rompe.
Estudios recientes de IDC y MIT muestran que entre el 88 y el 95 por ciento de los pilotos de AI empresarial no llegan a producción. La causa raíz no es el modelo de lenguaje. Es la complejidad de la integración segura, y cada mes que se pasa reconstruyendo la plomería de autenticación es un mes en que tus agentes no generan valor de negocio.
Puntos clave
- Usa un runtime MCP como capa de acción segura entre tus agentes y las herramientas empresariales. Evalúa la intersección de permisos del agente y permisos del usuario por acción, en tiempo de ejecución.
- Ejecuta cada llamada a herramienta en nombre del usuario (OBO). El agente actúa con las credenciales del usuario, acotadas a sus permisos nativos, y cada acción queda atribuible en los registros de auditoría.
- Mantén los tokens OAuth fuera del contexto del LLM. Las credenciales deben estar en un vault en la capa del runtime, donde el modelo no pueda observarlas, alterarlas ni filtrarlas.
- No uses cuentas de servicio estáticas. Rompen los modelos de permisos y convierten una sola inyección de prompt en un incidente a escala empresarial.
- Construye con herramientas optimizadas para agentes, no con wrappers crudos de API: operaciones a nivel de intención con esquemas validados que previenen alucinaciones de parámetros y eliminan los ciclos de reintento.
- Exige aprobaciones humanas en el flujo para todas las acciones destructivas. Eliminaciones, actualizaciones masivas y comunicaciones externas deben pausarse para una autorización explícita antes de ejecutarse.
- Implementa logs de auditoría y telemetría desde el primer día. Exporta cada llamada a herramienta vía OpenTelemetry a tu SIEM para cumplimiento, respuesta a incidentes y análisis de causa raíz.
Por qué conectar agentes de AI a herramientas empresariales es difícil: identidad, permisos y ejecución segura
El cuello de botella en sistemas agénticos, como Claude Cowork o OpenClaw, no está en hacer llamadas a la API. Está en la propagación de identidad, la herencia de permisos y la ejecución segura dentro de entornos empresariales complejos.
Cuando los equipos construyen integraciones directas entre LLMs y software empresarial, el roce aparece de inmediato. Los desarrolladores gastan ciclos gestionando ciclos de vida frágiles de tokens OAuth, manejando flujos de consentimiento de usuario asíncronos, ajustando manualmente los alcances de autorización de mínimo privilegio y construyendo controles de aprobación personalizados. Todo esto es trabajo de infraestructura sin diferenciación que quema tiempo de ingeniería sin avanzar las capacidades del agente.
Como este trabajo es tedioso y bloquea el desarrollo del agente, los equipos frecuentemente toman un atajo peligroso: usan cuentas de servicio.
Darle a un agente acceso global de lectura y escritura en toda una instancia empresarial rompe los modelos nativos de permisos. Estás saltándote años de controles de acceso basados en roles, cuidadosamente configurados.
Una sola entrada manipulada puede resultar en exfiltración de datos instantánea e indetectable, o en modificación del sistema. Si un agente tiene una API key estática con acceso de escritura global, una vulnerabilidad de inyección de prompt localizada se convierte en un radio de explosión a escala empresarial.
Los equipos cometen dos errores. Si le das al agente su propia identidad, un practicante puede saltarse sus permisos a través del agente. Si heredas el acceso completo del usuario, una sola inyección de prompt se propaga en cascada por cada sistema conectado.
La respuesta correcta es la intersección: qué tiene permitido hacer este agente Y qué tiene permitido hacer este usuario, evaluado por acción, en tiempo de ejecución. Este es el modelo de intersección de permisos, y es el único enfoque que previene simultáneamente tanto la escalada de privilegios como la expansión del radio de explosión.
Esta evaluación debe ocurrir en la capa del runtime. No al momento del login, no en el prompt y no en el código de la aplicación. Sin ella, escalar agentes más allá de demos de un solo usuario es inseguro.
El cambio arquitectónico: el agente ya es el proxy
Antes de evaluar enfoques de integración específicos, hay que entender por qué la arquitectura empresarial tradicional ya no aplica.
En el modelo pre-agéntico, un proxy (API gateway) se ubica entre las aplicaciones y las APIs para enrutar, autenticar y limitar el tráfico. El proxy es el punto de control porque todo el tráfico pasa por él.
Los agentes invierten esta topología. El agente media entre el usuario y la infraestructura, y ya gestiona el enrutamiento, la orquestación y la toma de decisiones. Agregar un proxy tradicional frente a las herramientas que llama el agente no añade un punto de control: añade un salto redundante que no puede ver el contexto de ejecución que importa: qué usuario, qué acción, qué permiso, en este momento.
El punto de control en una arquitectura agéntica es la capa de ejecución donde corre la herramienta, donde se resuelven las credenciales, se verifican los permisos y se ejecutan acciones en nombre de un humano específico. Eso es el runtime.
La era del gateway estuvo definida por el proxy como punto de control. La era agéntica está definida por el runtime.
Cuatro arquitecturas para conectar agentes de AI a herramientas empresariales
Conforme las organizaciones pasan de pilotos aislados a despliegues en producción, los equipos de ingeniería adoptan uno de cuatro modelos de integración. Entender dónde falla cada enfoque bajo carga empresarial es clave para la planificación arquitectónica.
| Enfoque de integración | Seguridad e identidad | Carga de mantenimiento | Confiabilidad y ejecución | Tiempo al mercado |
|---|---|---|---|---|
| Conectores personalizados y auth DIY | Muy variable; suele caer en llaves estáticas. | Extremadamente alta; requiere equipos dedicados de auth. | Baja; propensa a bucles de alucinación de parámetros. | Muy lento. |
| iPaaS heredado | Moderada; tiene problemas con ejecución On-Behalf-Of. | Media; depende de mantener flujos visuales. | Media; optimizada para disparadores lineales, no bucles. | Moderado. |
| Servidores MCP no administrados | Baja; carece de autorización centralizada multi-usuario. | Alta; requiere despliegue y parches manuales. | Baja; sin reintentos nativos ni estado de failover. | Rápido para prototipos. |
| Runtime MCP (p. ej., Arcade) | Alta; mapeo nativo de permisos y bóvedas de tokens. | Baja; el runtime gestiona el ciclo de vida y las actualizaciones. | Alta; ejecución paralela y reintentos automáticos. | Muy rápido. |
Enfoque 1: Construir conectores personalizados y OAuth (autenticación DIY)
Crea wrappers de API a medida y capas OAuth personalizadas para cada herramienta empresarial que necesite tu agente.
La ventaja es el control total. Decides cada aspecto de la integración y evitas la dependencia de terceros.
Pero las limitaciones se vuelven paralizantes rápido. Los conectores personalizados se convierten en un drenaje enorme de ingeniería. Los equipos pasan meses construyendo bóvedas de tokens seguras, gestionando la rotación de refresh tokens y escribiendo lógica para casos extremos. Meses que podrían haberse dedicado a enviar funciones del agente que realmente hagan avanzar el negocio.
Las APIs empresariales crudas complican más el problema. Esperan entradas altamente estructuradas y deterministas, pero los agentes generan lenguaje natural dinámico. Conectarlos directamente a endpoints crudos genera alucinaciones de parámetros y bucles infinitos de reintentos. La autenticación por sí sola se convierte en un proyecto de infraestructura independiente: rotación de tokens, vinculación de usuarios, validación de sesiones.
Enfoque 2: Usar iPaaS heredado para llamadas a herramientas del agente
Las empresas adaptan plataformas de integración existentes como Workato, MuleSoft o Zapier para disparar acciones basadas en los outputs del LLM.
La fortaleza es la familiaridad. Los equipos de TI empresariales ya conocen estas herramientas y vienen con catálogos enormes de endpoints preconfigurados.
Pero las limitaciones son arquitectónicas y fundamentales. Estas plataformas se construyeron para automatización lineal, determinista y basada en disparadores. Los sistemas agénticos operan con bucles de razonamiento no deterministas y con estado, donde el agente decide qué llamar, cuándo y cuántas veces según los resultados intermedios. Forzar eso en un patrón lineal de webhooks falla rápidamente.
El problema más profundo es la identidad. Las plataformas iPaaS heredadas se centran en cuentas de servicio entre sistemas. Carecen de ejecución verdadera por usuario, On-Behalf-Of (OBO), lo que obliga a los equipos a construir soluciones complejas y frágiles para garantizar que el agente solo actúe con los permisos específicos del usuario que escribe el prompt. La autorización por usuario evaluada en runtime en cada llamada a herramienta requiere una infraestructura que estas plataformas nunca fueron diseñadas para ofrecer.
Enfoque 3: Ejecutar servidores MCP no administrados
El Model Context Protocol estandarizó cómo los modelos de AI se conectan a fuentes de datos y herramientas. Con este enfoque, los equipos despliegan servidores MCP de código abierto para exponer capacidades locales o de SaaS directamente a sus agentes.
La fortaleza de MCP es la estandarización. Desacopla el framework del agente de la implementación subyacente de la herramienta, creando un lenguaje universal para llamadas a herramientas. El problema es que la calidad de los servidores MCP de código abierto no administrados varía mucho. Según benchmarks muchos tienen problemas de confiabilidad y exactitud, lo que agrava los desafíos de los despliegues en producción.
Estos servidores se rompen en cuanto los llevas a producción. Los servidores MCP crudos y no administrados carecen de gobernanza centralizada. No incluyen manejo de autenticación empresarial multi-usuario, lo que significa que todos los usuarios suelen compartir la misma identidad de conexión.
También carecen de funciones de confiabilidad en producción como reintentos automáticos, ejecución paralela y failover con estado desde el inicio. Esa carga recae en el desarrollador de la aplicación.
Enfoque 4: Usar un runtime MCP (la capa de acciones segura)
Un runtime MCP es la capa de infraestructura diseñada específicamente para resolver este problema. Arcade.dev, el primer runtime de MCP de la industria, combina herramientas optimizadas para agentes, autenticación y autorización centralizadas, y gobernanza empresarial en un único plano de control.
Este enfoque apunta específicamente a AI en producción. El runtime habla MCP de forma nativa (JSON-RPC, Streamable HTTP) sin traducción de protocolo ni pérdida de contexto. Preserva los permisos nativos mediante flujos de tokens On-Behalf-Of, aísla las credenciales del modelo de lenguaje y genera logs de auditoría instantáneos compatibles con OpenTelemetry para cada acción.
Los equipos lanzan más rápido porque el runtime se encarga de la autorización, el ciclo de vida de los tokens, los reintentos y la gobernanza. Los ingenieros se concentran por completo en la lógica del agente y los resultados de negocio.
El MCP Gateway de Arcade permite que cualquier cliente MCP acceda al catálogo completo de herramientas a través de un único endpoint. Los equipos también pueden incorporar sus propios servidores MCP al runtime para obtener autorización, reintentos y logs de auditoría sin reescribir lo que ya funciona. El runtime extiende tu inversión en MCP existente en lugar de reemplazarla.
Para proyectos de hobbyist de un solo usuario o scripts locales, un runtime completo agrega una carga innecesaria. Pero para equipos de ingeniería de plataforma que despliegan sistemas autónomos a miles de usuarios corporativos, un runtime de MCP es el único camino viable hacia producción.
Lo que exige la producción: autorización, herramientas y gobernanza
La comparación anterior muestra dónde falla cada enfoque. Pero entender por qué gana el runtime de MCP requiere profundizar en las tres capacidades que separan los despliegues en producción de las demos: autorización just-in-time que aplica acceso con alcance por usuario, herramientas optimizadas para agentes que eliminan los bucles de alucinación, e infraestructura de gobernanza que da a los equipos de plataforma visibilidad total sobre cada acción.
Cómo la autorización just-in-time aplica el acceso con alcance por usuario
Los conectores personalizados recurren a claves estáticas. Las plataformas iPaaS heredadas dependen de cuentas de servicio compartidas. Los servidores MCP no administrados carecen por completo de autenticación multiusuario. Los tres fallan en el mismo punto: no pueden evaluar quién tiene permiso de hacer qué en el momento en que se llama a la herramienta.
Ese es el problema que resuelve la autorización just-in-time.
El agente solicita y valida credenciales solo en el momento en que una acción las requiere, no de antemano. Si un usuario nunca activa la integración con Salesforce, no se obtienen ni almacenan tokens de Salesforce.
Todo el flujo de autenticación (intercambios OAuth, renovación de tokens, almacenamiento de credenciales) se ejecuta en lógica de backend determinista que el LLM nunca puede alterar, observar ni filtrar. Para mayor gobernanza, los equipos pueden agregar hooks antes y después de la llamada a la herramienta para aplicar políticas personalizadas, como aprobaciones humanas en el ciclo para ciertas acciones, límites de uso o reglas de acceso contextual.
Esto funciona porque el runtime es stateful. Mantiene contexto por sesión y por usuario a lo largo de todo el ciclo de razonamiento del agente. Un proxy sin estado evalúa cada solicitud de forma aislada y no puede saber que una solicitud es el paso 3 de un flujo de 6 pasos, actuando en nombre de Alice, quien autorizó este alcance específico hace 4 minutos. El runtime sí puede, y ese contexto de sesión es lo que hace aplicable la autorización por usuario y por herramienta.
Aquí es donde el modelo de intersección de permisos descrito antes se vuelve operativo. La arquitectura aplica: Permisos del Agente ∩ Permisos del Usuario = Alcance de Acción Efectivo. El agente solo puede ejecutar una acción si tanto la política de rol del agente como los permisos nativos del usuario en el SaaS lo permiten explícitamente. Cualquier otra combinación se deniega.
Un ejemplo concreto: se construye un agente de AI empresarial para asistir al departamento de Recursos Humanos. Un empleado que usa este agente tiene privilegios administrativos de alto nivel en Workday, incluido acceso a datos de nómina global. Pero el agente de RR. HH. está limitado estrictamente a tareas de reclutamiento.
Dado que el runtime evalúa la intersección de estos permisos al momento de la llamada, el agente recibe una denegación cuando se le solicita acceder a los datos de nómina. El usuario tiene la autoridad, pero el alcance restringido del agente bloquea la acción. Esto detiene la exfiltración de datos y los ataques de confused deputy en seco.
Herramientas optimizadas para agentes vs. wrappers de API: cuál usar y por qué
La tabla comparativa señala un modo de falla específico para los conectores personalizados: los bucles de alucinación de parámetros. Esto ocurre porque los endpoints REST sin procesar requieren parámetros precisos y deterministas, mientras que los modelos de lenguaje producen lenguaje natural probabilístico. Conectar uno directamente al otro sin un intermediario es donde los agentes se rompen.
Los agentes necesitan herramientas a nivel de intención, no wrappers de API sin procesar. Una herramienta a nivel de intención absorbe la ambigüedad de la solicitud del agente y la traduce en una transacción segura y predecible. El resultado es ejecución más rápida, menos acciones fallidas y menores costos de inferencia, porque el agente no quema tokens en bucles de reintento.
La ejecución en producción también requiere características de confiabilidad en el runtime que las APIs sin procesar no ofrecen. El runtime proporciona contexto definido por el desarrollador para reintentos inteligentes, ejecución paralelizada para tareas de múltiples pasos y failover automático para manejar límites de tasa y errores de red transitorios sin interrupciones. Los esquemas estandarizados dentro de estas herramientas previenen la alucinación de parámetros, la causa más común de falla en agentes cuando se conectan modelos directamente a APIs.
Considera cómo funciona esto en la práctica. En lugar de que un agente llame a un endpoint de actualización de Salesforce sin procesar y falle porque alucinó un string de ID de etapa requerido, el agente usa una herramienta de progreso de alto nivel optimizada para agentes.
La herramienta entiende de forma nativa la intención del usuario de mover un trato a negociación. Su lógica interna busca de forma segura el ID exacto y correcto para esa instancia específica de Salesforce, valida la transición de estado y ejecuta la actualización sin riesgos. El modelo de lenguaje no necesita adivinar el esquema exacto de la base de datos. La acción se completa en la primera llamada, no en la quinta.
Gobernanza y observabilidad para acciones de agentes (logs de auditoría, OTel, versionado)
Los servidores MCP no administrados obtuvieron “Bajo” en confiabilidad y seguridad en la comparación anterior porque carecen de gobernanza centralizada. Una vez que los agentes ejecutan acciones reales en nombre de usuarios, los equipos de plataforma necesitan visibilidad y control totales sobre el ecosistema de integración. El runtime lo logra mediante tres mecanismos.
El filtrado de visibilidad garantiza que los agentes solo vean las herramientas específicas que el usuario actual tiene permiso de invocar. Si un usuario no tiene permiso para fusionar código en GitHub, la herramienta de fusión de GitHub no aparece en la ventana de contexto del agente.
Las trazas de auditoría detalladas registran cada acción por usuario, por servicio y por sesión de agente. Estos logs son exportables a herramientas SIEM estándar mediante OpenTelemetry (OTel) para satisfacer auditorías de cumplimiento.
El control de versiones permite a los ingenieros de plataforma actualizar esquemas de herramientas y rotar parámetros de conexión de forma segura, sin interrumpir agentes en producción que están ejecutándose en versiones anteriores durante una sesión activa.
Cuando un agente cierra incorrectamente varias oportunidades abiertas en un CRM, el equipo de plataforma no puede pasar días analizando logs sin procesar. Con un registro de auditoría compatible con OTel generado por la capa de acción, el equipo de seguridad puede rastrear al instante la acción destructiva hasta el prompt exacto del usuario, la sesión específica del agente y el token utilizado. Esto aísla la causa raíz en minutos, y los equipos pueden refinar las instrucciones del agente o la política de acceso de la herramienta de inmediato.
De los cuatro enfoques evaluados, solo el runtime de MCP cumple los tres criterios: autorización con alcance de usuario en el momento de la llamada, herramientas a nivel de intención que previenen alucinaciones y gobernanza centralizada con trazas de auditoría completas. Las secciones siguientes muestran cómo funciona esta arquitectura en la práctica y cómo evaluarla para tu organización.
Cómo elegir un enfoque de integración de agentes de AI empresarial (seguridad, OBO y TCO)
Decidir cómo conectar tus agentes de AI a las herramientas empresariales es una decisión arquitectónica fundamental. Define la velocidad y la seguridad de tu despliegue. Los ingenieros de plataforma y los líderes técnicos deben enmarcar sus criterios de compra y construcción en torno a la seguridad, la escala y dónde deben enfocarse sus recursos de ingeniería.
Requisitos de seguridad y cumplimiento (SOC 2, ISO 27001, trazabilidad)
¿La solución propuesta puede mapear de forma nativa los requisitos de SOC 2 e ISO 27001 para la atribución estricta de usuarios? Si un agente elimina un archivo en Google Workspace, el registro de auditoría debe probar de forma definitiva qué persona autorizó esa acción.
El sistema debe soportar aprobaciones de Human-in-the-Loop (HITL) previas a la llamada a herramientas. Las acciones destructivas, como modificar configuraciones de producción o actualizar registros de base de datos en masa, deben pausar la ejecución y requerir la firma criptográfica de un administrador humano vía Slack o correo antes de continuar.
Economía de construir vs. comprar (mantenimiento de OAuth y costo total de propiedad)
La decisión de construir o comprar exige una evaluación económica sin contemplaciones.
Calcula las horas de ingeniería reales que se necesitan para construir, mantener y actualizar de forma segura los flujos de OAuth para diez o más APIs empresariales distintas. Incluye los costos ocultos: gestionar la rotación de refresh tokens, construir URLs de callback para tareas asíncronas de larga duración, parchear conectores personalizados cada vez que los proveedores SaaS deprecan sus versiones de API.
Luego pregúntate qué habrían podido entregar esos ingenieros en ese tiempo.
Adoptar un runtime de MCP convierte un proyecto de infraestructura de varios meses en un ejercicio de configuración. El costo total de propiedad cae drásticamente, y tu equipo recupera meses de capacidad de ingeniería para invertirlos en las capacidades del agente que diferencian tu producto.
Tiempo de obtención de valor y enfoque de ingeniería
El tiempo de obtención de valor es donde la mayoría de los equipos subestima el costo de construir internamente.
¿Tus ingenieros de AI van a pasar los próximos tres meses construyendo conectores confiables para Slack y Workspace, o van a usar ese tiempo optimizando prompts, evaluando lógica de razonamiento y entregando las capacidades de agente que generan ingresos? Cada semana invertida en plumbing de integración es una semana que tus competidores usan para llevar sus agentes a producción.
Al evaluar proveedores externos o planes de arquitectura interna, presiona con preguntas técnicas concretas:
- ¿Las API keys o los tokens de OAuth son visibles en algún momento en la ventana de contexto del modelo de lenguaje?
- ¿Cómo resuelve el sistema los permisos en conflicto entre un usuario con privilegios altos y un agente con alcance limitado?
- ¿El sistema puede emitir contexto de traza estándar W3C a nuestros colectores de OpenTelemetry existentes?
- ¿Cómo maneja la herramienta el rate limiting cuando un agente entra en un ciclo de reintentos inesperado?
Si la respuesta sobre la visibilidad de credenciales es cualquier cosa que no sea aislamiento absoluto, la arquitectura no es apta para producción empresarial.
Arquitectura de referencia para un runtime de MCP (flujo paso a paso)
Con la decisión arquitectónica clara, así es como una solicitud fluye de principio a fin por el runtime. El runtime de MCP actúa como intermediario que gestiona la confianza y la ejecución entre el motor de razonamiento no determinista y el entorno empresarial determinista.
El flujo de una solicitud segura sigue una secuencia estricta:
- Prompt del usuario: el usuario envía una solicitud, por ejemplo, “cierra este ticket de soporte”.
- Plan del LLM: el modelo de lenguaje del agente determina la secuencia de llamadas a herramientas necesarias para cumplir la solicitud.
- Runtime de MCP: el runtime recibe la solicitud de llamada a herramienta, evalúa los permisos del usuario y del agente, y recupera la credencial On-Behalf-Of necesaria.
- Ejecución de la herramienta: el runtime, no el agente, ejecuta la llamada precisa a la API contra el sistema destino (por ejemplo, Zendesk).
- Resultado y siguiente acción: el runtime recibe el resultado de la API, lo filtra y lo devuelve al agente. El LLM planifica entonces la siguiente acción en la secuencia o determina que la tarea está completa.
- Confirmación y auditoría: el agente confirma al usuario que la acción se completó, y el runtime registra toda la transacción vía OpenTelemetry para fines de auditoría.
Esta arquitectura impone una separación estricta de responsabilidades. El modelo de lenguaje se encarga del razonamiento, la planificación, la selección de acciones y la generación. La capa de runtime gestiona las credenciales, el cumplimiento de políticas, el rate limiting, la ejecución de acciones y el logging.
Al guardar los tokens en la capa de runtime, esta arquitectura previene la exfiltración de datos provocada por inyección de prompts. El modelo de lenguaje nunca posee las claves necesarias para exportar datos.
Cómo funciona un runtime de MCP con cualquier LLM
El runtime de MCP funciona con cualquier LLM, a través de cualquier framework de orquestación o sin ninguno. No hay dependencia de framework. Arcade actúa como el backend seguro de ejecución: tu código maneja el razonamiento, Arcade maneja las credenciales, la autorización y la ejecución de herramientas.
Esta separación clara es lo que acelera el tiempo de producción. Los ingenieros de AI se concentran en la lógica del agente y delegan al runtime la parte más riesgosa: las integraciones empresariales.
Un ejemplo práctico: un agente que lee Gmail y envía mensajes en Slack a través del runtime de Arcade. La configuración requiere tres dependencias y tres variables de entorno:
pip install arcadepy openai python-dotenv# .env
ARCADE_API_KEY=your_arcade_api_key # Free at arcade.dev
ARCADE_USER_ID=your_email@company.com # The user the agent acts on behalf of
OPENAI_KEY=your_openai_keyfrom arcadepy import Arcade
from openai import OpenAI
from dotenv import load_dotenv
import json, os
load_dotenv()
arcade_client = Arcade()
arcade_user_id = os.getenv("ARCADE_USER_ID")
llm_client = OpenAI(
api_key=os.getenv("OPENAI_KEY"),
)
# Define enterprise productivity tools — Arcade handles auth for each
tool_catalog = [
"Gmail.ListEmails",
"Gmail.SendEmail",
"Slack.SendMessage",
]
# Get tool definitions formatted for the LLM
tool_definitions = [
arcade_client.tools.formatted.get(name=t, format="openai")
for t in tool_catalog
]
# JIT authorization + execution — credentials never touch the LLM
def authorize_and_run_tool(tool_name: str, input: str):
auth = arcade_client.tools.authorize(
tool_name=tool_name, user_id=arcade_user_id
)
if auth.status != "completed":
print(f"Authorize {tool_name}: {auth.url}")
arcade_client.auth.wait_for_completion(auth.id)
result = arcade_client.tools.execute(
tool_name=tool_name,
input=json.loads(input),
user_id=arcade_user_id,
)
return json.dumps(result.output.value)
# Agentic loop — LLM reasons and selects tools, Arcade executes them
def invoke_llm(history: list[dict], max_turns: int = 5) -> list[dict]:
turns = 0
while turns < max_turns:
turns += 1
response = llm_client.chat.completions.create(
model="gpt-4o-mini",
messages=history,
tools=tool_definitions,
tool_choice="auto",
)
msg = response.choices[0].message
if msg.tool_calls:
history.append(msg.model_dump(exclude_none=True))
for tc in msg.tool_calls:
result = authorize_and_run_tool(tc.function.name, tc.function.arguments)
history.append({"role": "tool", "tool_call_id": tc.id, "content": result})
continue
else:
history.append({"role": "assistant", "content": msg.content})
break
return history
# Run the agent
history = [{"role": "system", "content": "You are a helpful assistant."}]
history.append({"role": "user", "content": "Summarize my latest 5 emails, then send me a DM on Slack with the summary."})
history = invoke_llm(history)
print(history[-1]["content"])
El LLM razona sobre la tarea y selecciona Gmail.ListEmails para obtener los correos, los resume y luego selecciona Slack.SendMessage para enviar el resumen. El runtime gestiona la autorización JIT de cada herramienta en nombre del usuario específico. El agente nunca ve tokens OAuth, nunca gestiona flujos de refresco ni toca credenciales. Guía completa en la documentación de Arcade.
Siguientes pasos para llevar integraciones de agentes a producción (checklist)
Para pasar de prototipos en sandbox a despliegues de nivel productivo, los equipos de ingeniería de plataforma siguen un plan de implementación estructurado e iterativo.
Paso 1: Inventario de herramientas necesarias y permisos mínimos
Comienza con una auditoría rigurosa de las herramientas que necesitas. Lista las APIs específicas que requieren tus agentes y documenta los scopes de usuario y granularidades OAuth exactas para cada una. No pidas acceso global. Mapea el principio de mínimo privilegio en cada flujo de trabajo.
Paso 2: Define acciones autónomas vs. aprobadas por humanos (HITL)
Define tus límites operativos. Crea una matriz que decida qué acciones son seguras para ejecución autónoma (como leer eventos de calendario) y cuáles requieren delegación explícita del usuario o aprobación con un humano en el ciclo (como eliminar archivos o enviar correos externos).
Paso 3: Estandariza en un único plano de control
Centraliza tu estrategia de integración de inmediato. Evita la creación de “registros paralelos no controlados”.
Cuando equipos de ingeniería dispersos construyen integraciones redundantes con tokens codificados en el código, generan vulnerabilidades de seguridad graves y proliferación de integraciones. Estandariza en un único plano de control para todo el uso de herramientas de los agentes.
Paso 4: Pilotea un flujo de trabajo y valida el aislamiento de tokens y la telemetría
Antes de hacer un despliegue amplio, prueba la arquitectura con un caso de uso acotado y controlado. Pilotea un solo flujo, como la automatización de issues de desarrollo que conecta GitHub y Jira, para validar el aislamiento de tokens y la telemetría.
Invierte en infraestructura, no solo en conectores aislados. Evalúa plataformas que traten la autorización, las herramientas optimizadas para agentes y la gobernanza del ciclo de vida como un runtime seguro unificado, no como problemas separados.
Conclusión: usa un runtime de MCP para conectar agentes de AI a herramientas empresariales
El verdadero reto de conectar AI a herramientas de productividad empresarial tiene poco que ver con formatear payloads JSON o hacer llamadas a APIs. El cuello de botella está en asegurar el acceso con scope de usuario, aplicar permisos de mínimo privilegio en tiempo de ejecución y mantener una gobernanza operativa rigurosa sobre sistemas no deterministas.
Los equipos de ingeniería de plataforma más exitosos reconocen que reconstruir la propagación de identidad, los ciclos de vida de tokens y la mecánica de integración desde cero es una distracción costosa de sus objetivos de negocio. Necesitan un runtime de MCP, no más conectores personalizados.
Arcade es el primer runtime de MCP de la industria. Ofrece autorización segura de agentes, el catálogo más amplio de herramientas optimizadas para agentes y gobernanza centralizada del ciclo de vida en un único plano de control. Arcade elimina el trabajo pesado e indiferenciado de la integración empresarial para que tu equipo entregue más rápido y escale con control.
Si estás construyendo agentes que necesitan ejecutarse en herramientas empresariales, empieza con la guía de inicio o explora el catálogo completo de herramientas para ver qué está disponible desde el primer momento.
FAQ: Integraciones de agentes de AI empresariales
¿Cuál es la mejor forma de conectar agentes de AI a herramientas de productividad empresarial?
Usa un runtime de MCP, una capa de acción segura que ejecuta con scope de usuario (OBO), mantiene los tokens fuera del LLM y aplica autorización en tiempo de ejecución por cada llamada a herramienta.
¿Deben los agentes de AI usar cuentas de servicio para acceder a Slack, Google Workspace o Microsoft 365?
No. Las cuentas de servicio omiten los permisos del usuario y amplían el radio de daño de una inyección de prompts. Usa ejecución en nombre del usuario con scopes de mínimo privilegio.
¿Qué significa “On-Behalf-Of (OBO)” en las integraciones de agentes?
OBO significa que el agente ejecuta cada acción con credenciales vinculadas al usuario que hace la solicitud, por lo que la acción queda limitada a los permisos nativos de ese usuario y es atribuible en los registros de auditoría.
¿Qué es la autorización just-in-time para agentes de AI?
La autorización just-in-time es una verificación de política en tiempo de ejecución que se ejecuta en el momento de cada llamada a una herramienta, evaluando la identidad del usuario, el scope permitido del agente y la acción solicitada. Las credenciales se solicitan y validan solo cuando se necesitan, no se pre-autorizan durante la configuración.
¿Qué es un runtime de MCP y en qué se diferencia de un servidor MCP?
Un servidor MCP expone herramientas a un agente usando el MCP, pero generalmente es monousuario, sin estado y no incluye autenticación integrada, gestión de tokens ni observabilidad. Un runtime de MCP es la capa de infraestructura empresarial que complementa a los servidores MCP para agregar lo que les falta: autenticación OBO multiusuario, aplicación de políticas por llamada, almacenamiento seguro de tokens, reintentos automáticos y auditoría con telemetría. El servidor define qué puede llamar el agente; el runtime hace que sea seguro llamarlo a escala. Arcade es el primer runtime de MCP de la industria, diseñado para despliegues de agentes en producción.
¿Cuáles son los requisitos mínimos de seguridad para el acceso de herramientas de agentes en producción?
Aislamiento de tokens del LLM, ejecución con alcance de usuario/OBO, permisos de mínimo privilegio, autorización por acción, registros de auditoría con atribución de usuario y aprobaciones HITL para acciones de alto riesgo.
¿Cómo auditas y atribuyes las acciones de agentes para cumplimiento normativo (SOC 2 / ISO 27001)?
Registra cada llamada a herramienta con la identidad del usuario, la herramienta, parámetros/intención, resultado y contexto de traza; expórtalos vía OpenTelemetry a tu SIEM para investigación e informes.
¿Cuándo fallan las herramientas iPaaS heredadas (Zapier/Workato/MuleSoft) con agentes?
Les cuesta manejar los bucles no deterministas de agentes y la ejecución OBO con alcance de usuario real, lo que obliga a los equipos a usar credenciales compartidas o soluciones frágiles.
¿Cómo reducen las alucinaciones las herramientas optimizadas para agentes frente a los wrappers de API?
Usan operaciones a nivel de intención con esquemas validados y búsquedas internas, así el modelo no tiene que adivinar IDs o parámetros requeridos y puede fallar de forma segura.
¿Cuándo debemos agregar aprobaciones de humano en el proceso (HITL)?
Para acciones destructivas o irreversibles (eliminaciones, correos externos, actualizaciones masivas, cambios de permisos) o cualquier acción que afecte de forma significativa la seguridad, las finanzas o los datos de clientes.
