Por Sterling Dreyer (Ingeniero Fundador), Guru Sattanathan (Arquitecto Principal de Soluciones)
TL;DR: Arcade.dev protege la ejecución de herramientas de agentes de AI con identidad delegada, acceso acotado y gobernanza. Hoy extendemos ese modelo de seguridad con Contextual Access: hooks de runtime que te permiten inyectar tu propia lógica de seguridad, cumplimiento y filtrado directamente en el pipeline de ejecución de herramientas, en tres puntos de enganche, vía cualquier webhook en cada llamada.
El Problema: Hacer que los Agentes de AI Pasen el Filtro de Seguridad
Esto es lo que pasa cuando una empresa intenta desplegar agentes de AI: el agente necesita acceso a herramientas como SAP, Snowflake, Gmail y tus APIs internas, y el equipo de seguridad necesita respuestas. ¿Quién autorizó este agente? ¿A qué puede acceder? ¿Qué pasa cuando algo sale mal?
Aquí es donde la mayoría de los agentes nunca llegan a producción. La mayoría de los equipos empieza creando cuentas de servicio para cada agente, generando API keys e incrustando tokens en el contexto del LLM. Esto se vuelve imposible de gestionar rápidamente: nuevas identidades que gobernar, nuevas credenciales que proteger. Y aun así, los agentes raramente pasan la revisión de seguridad.
Arcade fue creado para resolver esto y que puedas lanzar agentes de AI que el equipo de seguridad apruebe. Integrado en el runtime de MCP, Arcade ofrece tres capas de seguridad: aplicación de políticas, acceso acotado a herramientas y acceso contextual. Sin cuentas de servicio que gestionar, sin credenciales en el contexto del LLM y sin ciclos de aprobación nuevos por cada agente que despliegues.
Cómo Arcade Resuelve la Seguridad para Agentes de AI Empresariales
El modelo de seguridad de Arcade funciona en tres capas. Son independientes y acumulativas, lo que te da una defensa en profundidad para la ejecución de herramientas de agentes de AI, todo integrado directamente en el runtime de MCP.
Capa 1: Aplicación de Políticas para Agentes de AI - Tu Identidad, Tus Reglas
Cuando un agente de AI ejecuta una herramienta a través de Arcade, no usa una cuenta de servicio ni genera una nueva API key. El agente actúa en nombre del usuario, con su identidad existente, gobernado por las políticas que tu equipo de IT ya gestiona: Entra ID, Okta o lo que uses hoy.
Si Jim, de la cadena de suministro, puede acceder a tres códigos de transacción SAP, eso es exactamente lo que puede hacer un agente que opere en su nombre, ni un byte más. Y los tokens de usuario nunca tocan el contexto del LLM. Arcade gestiona el ciclo completo de OAuth en un runtime aislado, así que el agente nunca ve una credencial ni un secreto.
Capa 2: Acceso Acotado por Agente - Acceso ≠ Capacidad
La Capa 1 garantiza que un agente no supere los permisos del usuario. La Capa 2 te permite restringir aún más lo que el agente puede hacer dentro de esos permisos.
Un usuario podría tener acceso completo a Gmail: leer, enviar, eliminar. ¿Pero debería su agente tener acceso para eliminar? Tu equipo de gobernanza que construye agentes acota el conjunto de herramientas de cada agente para exponer solo las operaciones que tienen sentido. Nosotros lo hacemos con nuestros propios agentes internos: una asistente ejecutiva en Arcade tiene acceso completo a Gmail de la cuenta del CEO como usuaria, pero eliminamos el scope de borrado de su agente. El agente del gerente de cadena de suministro obtiene herramientas de seguimiento de pedidos. El agente del equipo de finanzas obtiene herramientas de reportes. Cada agente ve solo lo relevante y solo puede hacer lo que fue aprobado.
Estas dos capas ya ponen a Arcade muy por delante de lo que otros runtimes de agentes ofrecen de forma nativa. Para la mayoría de los despliegues, cubren el grueso de los requisitos de seguridad empresarial. Pero “la mayoría” no es “todo”.
Capa 3: Acceso Contextual - Políticas Sofisticadas en Runtime
Las Capas 1 y 2 responden quién puede hacer qué. Pero algunas políticas no se pueden expresar solo con identidad y scoping de herramientas. El agente de un usuario puede estar configurado para enviar correos, pero nada en el modelo OAuth de Gmail puede restringirlo a dominios internos únicamente.
Hoy lanzamos Contextual Access, un sistema que te permite inyectar tu propia lógica de seguridad, cumplimiento y filtrado directamente en el pipeline de ejecución de herramientas de Arcade. Tres puntos de enganche te permiten interceptar las llamadas a herramientas en los momentos clave: antes de que el agente vea una herramienta, antes de que una herramienta se ejecute y después de que una herramienta devuelva su resultado.
Ejemplos Prácticos de Políticas:
Inyección de prompts: Un agente envía una consulta a SAP con un payload incrustado. Con Contextual Access, la consulta nunca se ejecuta.
Salidas de herramientas envenenadas: Una herramienta de scraping devuelve contenido con instrucciones de secuestro. El payload se elimina antes de que el LLM lo vea.
PII en respuestas: Una herramienta devuelve registros de clientes con campos sensibles. Se redactan antes de entrar al contexto del modelo.
Patrones sospechosos: Una secuencia de llamadas parece exfiltración de datos. La secuencia se detecta y bloquea en tiempo real.
Los Tres Puntos de Enganche
Contextual Access te da tres puntos de enganche en el runtime de MCP de Arcade, tanto para llamadas a herramientas de API como de servidor MCP. Cada uno es un punto de control independiente donde inyectas tu propia lógica vía webhooks, y juntos forman un pipeline de seguridad completo alrededor de cada llamada a herramienta.
Access Hook: Controla la Visibilidad de Herramientas
El Access hook es un hook en el runtime de Arcade que te permite controlar qué herramientas puede descubrir un agente. Se activa cuando el agente solicita la lista de herramientas disponibles, antes de que el agente sepa siquiera que una herramienta existe.
Conéctalo a tu motor de permisos, tu lógica de RBAC personalizada o cualquier sistema externo que tome decisiones de acceso. El agente solicita las herramientas disponibles, Arcade llama a tu webhook y tu sistema devuelve la lista filtrada. Un agente que no puede ver una herramienta no puede llamarla, y un agente que no puede llamarla no puede ser manipulado para hacer un mal uso de ella.
El soporte por lotes significa que una sola llamada al webhook puede evaluar todo el catálogo de herramientas sin el problema N+1 al listar cientos de herramientas. Los resultados se cachean con un tiempo de vida (TTL) configurable para no agregar latencia en cada turno del chat. La invalidación de caché ocurre automáticamente cuando cambian las configuraciones de hooks, o puedes activarla manualmente vía API.
Cuándo se ejecuta:
- Listado de herramientas: filtra el catálogo antes de que el agente lo vea
- Antes de la ejecución: revalida por si los permisos cambiaron desde el último caché
Pre-Execution Hook: Controla Cada Llamada a Herramienta
El Pre-Execution hook es un hook en el runtime de Arcade que te permite validar, transformar o bloquear cualquier llamada a herramienta antes de que se ejecute. Aquí ocurre la aplicación de políticas en tiempo real. Puedes detectar cosas que la identidad y el scoping no pueden.
Qué recibe tu hook:
- Identidad de la herramienta (nombre, toolkit, versión)
- Todos los inputs que el agente pasa a la herramienta
- Contexto del usuario (ID de usuario, información de autorización)
Qué puede hacer tu hook:
- Permitir: continuar tal como está
- Permitir con modificaciones: sobreescribir inputs, inyectar parámetros por usuario, mapear IDs legibles a UUIDs internos, enrutar a backends específicos
- Denegar: bloquear la ejecución con una razón que se devuelve al agente
Un cliente de servicios financieros exige que las herramientas de correo solo envíen dentro del dominio de la organización. Un cliente de manufactura valida que los códigos de transacción SAP coincidan con la asignación de planta del usuario. Un cliente de salud garantiza que las consultas de registros de pacientes incluyan los parámetros de consentimiento requeridos.
Si tu Pre-Execution hook dice no, la herramienta nunca se ejecuta y el sistema de destino nunca ve la solicitud, lo que mantiene el radio de impacto lo más pequeño posible.
Post-Execution Hook: Controla lo que Regresa
El Post-Execution hook es un hook en el runtime de Arcade que te permite escanear, redactar o bloquear la salida de una herramienta antes de que llegue al LLM. Es tu última línea de defensa antes de que los datos entren al contexto del modelo.
Qué recibe tu hook:
- Todo el contexto de pre-ejecución (identidad de la herramienta, inputs, contexto del usuario)
- ID de ejecución (correlaciona con el pre-execution hook para trazabilidad de extremo a extremo)
- Estado de éxito/falla
- La salida completa de la herramienta
Qué puede hacer tu hook:
- Permitir: devolver la salida tal como está
- Permitir con modificaciones: redactar campos, transformar datos, eliminar contenido sensible
- Denegar: reemplazar la salida completamente con un mensaje de error; el agente nunca ve el original
Aquí es donde manejas la redacción de PII y detectas los payloads de inyección de prompts más peligrosos: los incrustados en datos que devuelven las herramientas, no en los prompts del usuario, y capturas el contexto completo de ejecución para los registros de cumplimiento.
Contextual Access protege en ambas direcciones: protege las herramientas del agente y protege al agente de las herramientas.
Aplicando Seguridad Compleja y Componible con Contextual Access
Múltiples hooks en el mismo punto de enganche se ejecutan como un pipeline, ordenados por prioridad. Cada hook ve la salida acumulada de todos los hooks anteriores. Esto te permite construir protecciones sofisticadas que se aplican automáticamente en cada llamada a herramienta, sin que ningún hook individual necesite saber de los demás.
Cadena Pre-Execution: El Hook A enriquece el input con parámetros adicionales → el Hook B valida esos parámetros → el Hook C registra la solicitud final.
Cadena Post-Execution: El Hook A redacta PII de la salida → el Hook B escanea la salida redactada en busca de inyección de prompts → el Hook C nunca ve los valores sensibles originales.
Cadena Access: El Hook A devuelve el subconjunto de herramientas a las que el usuario puede acceder → el Hook B solo evalúa las herramientas que pasaron el Hook A.
La cadena se detiene de inmediato cuando cualquier hook deniega; los hooks posteriores no se ejecutan, porque un solo rechazo es suficiente para bloquear la llamada.
Cómo Configurar Contextual Access a Nivel de Organización y Proyecto
Los Hooks de Contextual Access se configuran en dos niveles, y ambos se ejecutan siempre:
- A nivel de organización- Políticas de toda la empresa aplicadas a cada proyecto
- A nivel de proyecto- Reglas específicas del equipo acotadas a casos de uso individuales
El flujo de ejecución sigue una secuencia estricta de tres fases:
Fase 1: Hooks de organización (antes): cumplimiento a nivel de toda la empresa primero
Fase 2: Hooks de proyecto: validación y filtrado específico del equipo
Fase 3: Hooks de organización (después): redacción de PII y auditoría a nivel de organización
Las modificaciones se acumulan en todas las fases. Si el pre-hook de organización inyecta un parámetro de cumplimiento, el pre-hook de proyecto lo ve. Si el post-hook de proyecto redacta un campo, el post-hook de organización ve la versión redactada.
Cómo Controlar los Modos de Falla con Contextual Access
Cada hook de Contextual Access se configura con un modo de falla para cuando el webhook no es alcanzable:
- fail_closed - Bloquea la operación. Para verificaciones críticas de seguridad donde “no sé” significa “no”.
- fail_open - Permite la operación. Para mejoras no críticas como métricas o logging.
Configuras esto por hook, porque que un escáner de PII falle no debería tener el mismo impacto que un recolector de telemetría.
El soporte de reintentos está integrado con máximo de intentos configurable, backoff exponencial y reintentos solo ante fallas transitorias (5xx, timeouts, errores de conexión).
Prueba Contextual Access en Producción Sin Riesgo
Cualquier hook de Contextual Access puede configurarse en modo dry-run para probarlo antes de que llegue a producción. En dry-run:
- Tu webhook se llama con solicitudes reales de producción
- Pero nada se aplica; la ejecución de herramientas continúa como si el hook hubiera devuelto “allow”
Esto te permite validar la lógica de un nuevo hook contra tráfico real antes de activar el enforcement. Ves exactamente qué habría sido bloqueado, qué habría sido modificado y qué latencia agrega tu webhook, todo sin tocar ni un flujo de producción.
Webhooks: Lleva Tus Políticas a los Agentes de AI
Seguimos expandiendo las formas en que puedes aplicar las políticas de seguridad de tu organización a los agentes de AI. Empezamos con webhooks porque te dan la mayor flexibilidad; tus políticas son tuyas y no hay dos empresas que apliquen el control de acceso de la misma manera.
Un webhook te permite implementar exactamente tu lógica, en tu lenguaje, en tu infraestructura, hoy. El contrato es limpio y bien definido:
- Autenticación: Bearer token o mTLS para redes zero-trust
- Health checks: Intervalos configurables con estado saludable/degradado/no saludable visible en el dashboard
- Spec OpenAPI 3.0 completo: Disponible enGitHubcon esquemas completos de solicitud/respuesta para los tres puntos de enganche
- Versionado: Cada cambio de configuración se versiona con soporte de rollback
Empezamos con webhooks y seguiremos construyendo integraciones directas con proveedores de seguridad como Snyk, sistemas de identidad y permisos como Sailpoint y Okta, y más. Se conectarán a la misma arquitectura de hooks, así que tus configuraciones de webhook existentes funcionarán junto a las integraciones nativas a medida que tu stack evolucione.
Empieza Ahora
Contextual Access está disponible hoy para todos los clientes de Arcade.
- Lee la documentación:Referencia completa de API, esquemas de webhook y guías de configuración.
- Despliega un webhook:Empieza con un pass-through simple e itera.
- Configura tus hooks:Access, Pre-Execution, Post-Execution: elige lo que más importa primero.
- Activa dry-run: Valida contra tráfico real antes de activar el enforcement
- Encadena y compón: Agrega hooks de forma incremental según evolucionen tus requisitos
Publicamos servidores webhook de ejemplo para que puedas empezar. La especificación completa de la API de webhook está disponibleen GitHub →
Regístrate gratis y empieza a construir →arcade.dev
