Gobierne cada agente, no solo cada petición.
Un agente convierte una instrucción en decenas de llamadas a modelos, herramientas y otros agentes. Wäg se sitúa delante de todas y sabe qué agente actúa, para qué persona, qué puede tocar, qué puede gastar y quién aprobó el paso arriesgado — y puede demostrarlo después. Construya agentes donde quiera: lo alcanzan todo pasando por aquí.
Un agente no es una petición más grande.
Una petición de chat es una decisión que usted permite o rechaza. Un agente es un bucle: lee un documento, llama a una herramienta, lee el resultado, llama a otra y sigue hasta que se da por terminado. Los fallos caros no son las malas respuestas. Son el bucle que no se detiene, la herramienta que cambió en silencio, los datos que salieron por una llamada que nadie inspeccionó y la credencial que vive para siempre en una variable de entorno.
MCP y A2A identifican al agente y la cuenta que usa. Ninguno lleva el dato que un auditor pide primero: qué persona autorizó ese paso concreto. Wäg escribe la identidad de quien aprueba en la propia llamada, en una entrada encadenada por hash que puede verificar sin conexión.
Trece controles, en el orden en que aparecen
Apache-2.0 salvo donde se indique. Todo se aplica a los agentes que construya en cualquier parte — LangGraph, Bedrock AgentCore, Vertex, Foundry, Claude Code o su propio bucle — porque todos alcanzan modelos, herramientas y otros agentes a través de la pasarela.
Los agentes son principales
Un agente es una identidad de pleno derecho, con un responsable humano, un runtime declarado, un nivel de riesgo y una finalidad. Cada petición lleva el agente y la persona por la que actúa al registro de peticiones y al libro de evidencias.
Ejecuciones, y límites que las paran
Una ejecución es una tarea del agente. Limite sus peticiones, llamadas a herramientas, tokens, coste y duración. Pasado el límite, la siguiente petición de la ejecución se rechaza y quien llama sabe qué límite alcanzó — antes de la factura, no después.
Política de herramientas: el cortafuegos de agentes
Reglas ordenadas deciden cada llamada: permitir, denegar, clasificar con un modelo o retener para una persona. Las condiciones leen los argumentos y a quien llama, así que "los reembolsos por encima de 1.000 requieren aprobación" es una sola regla. El ensayo cuenta lo que habría hecho una regla y "Probar una llamada" muestra cuál decide — en la consola o en CI.
Aprobaciones con un nombre detrás
Una llamada retenida espera a una persona, no a un indicador. Los aprobadores son usuarios o equipos, la autoaprobación se rechaza por defecto y cada solicitud caduca. Deciden en la consola o con una petición dentro de su propio cliente MCP, y un correo puede avisarles de que hay una solicitud esperando; decidir en Slack o Microsoft Teams es Enterprise. La decisión y quien la tomó quedan en el libro.
Control de flujos de datos
Las herramientas llevan etiquetas: devuelve datos privados, devuelve contenido que controlan terceros, puede sacar datos. Cuando una ejecución ha tocado las dos primeras, la tercera se rechaza o se retiene: el trío letal, cerrado por construcción. También alcanza al dato concreto, mediante huellas cifradas de lo que devolvió una herramienta sensible, nunca el texto.
Fijación de herramientas
Cada herramienta MCP queda fijada a la definición que aprobó un administrador: nombre, descripción, esquemas y anotaciones, de modo que una herramienta que deja de ser de solo lectura cuenta como cambiada. Si un servidor cambia una, queda en cuarentena hasta que una persona revise la diferencia y la acepte. Los cambios silenciosos dejan de serlo.
Sin claves permanentes
Los agentes obtienen credenciales que duran minutos y se identifican con un par de claves registrado en lugar de un secreto compartido, ligadas a una sola ejecución si lo desea. DPoP deja inútil un token copiado; también funcionan el TLS mutuo y las identidades SPIFFE, y las claves duraderas pueden prohibirse del todo.
Salida gestionada
Los agentes alcanzan API de terceros a través de un destino registrado, y la pasarela añade la credencial: el agente nunca guarda la clave, y sus propias cabeceras de autenticación se eliminan por el camino. Cada destino fija qué métodos y rutas admite, y cada llamada pasa por la política de herramientas, las aprobaciones, los presupuestos, las barreras, la residencia y el libro de evidencias como cualquier otra.
Cada conexión saliente
Apunte el HTTPS_PROXY de un agente a la pasarela y todo su tráfico web pasa por el plano de control, no solo sus llamadas a modelos y herramientas. Las reglas de host deciden a qué sitios puede llegar, y cada conexión se trata como una llamada a herramienta: se aplican la política, las aprobaciones y las etiquetas de flujo de datos, y cuenta en la ejecución. El nombre TLS debe coincidir con el host solicitado, el client hello cifrado se rechaza y los túneles abiertos se cierran en segundos cuando se retira un permiso o se detiene al agente. Abrir el TLS de hosts seleccionados, para que dentro se apliquen las reglas de petición y las barreras, es Enterprise.
Otros agentes, detrás de sus claves
Registre un agente remoto por su agent card A2A, y sus personas y agentes lo llaman en /v1/a2a con sus credenciales habituales. El agente remoto solo ve la credencial de la pasarela, y cada mensaje pasa por comprobaciones de acceso, presupuestos, barreras, límites de ejecución, política de herramientas y evidencias como una llamada a un modelo.
Inventario e interruptor de emergencia
Encuentre los agentes que nadie registró — Wäg los reconoce por cómo se comporta su tráfico — y los servidores MCP que sus desarrolladores ejecutan en sus propias máquinas, por los nombres de herramienta que llevan sus peticiones. Dé a cada uno una fecha de revisión y una caducidad que se aplica de verdad. Si algo sale mal, detenga una ejecución, un agente o todos los agentes de una organización, en cada réplica y región a la vez.
Agentes de otras plataformas Enterprise
Importe al inventario los agentes que ya conocen Microsoft Foundry, AWS Agent Registry, Microsoft Entra Agent ID y Gemini Enterprise, y manténgalos sincronizados. Cada uno recibe un responsable, un nivel de riesgo, límites de ejecución y políticas de herramientas; sus instrucciones y credenciales nunca se leen.
Pagos de agentes Enterprise
Dé a un agente un mandato de gasto en lugar de una tarjeta: su propio presupuesto por moneda, aprobación por encima de un umbral y constancia de cada pago. Raíles para x402, mandatos AP2 y pago ACP o UCP, con la pasarela guardando la credencial o verificando a un agente que guarda la suya.
Pruebas, no una captura del panel
Una gobernanza que no se puede evidenciar es una intención. Cada decisión anterior acaba en el mismo sitio: un libro encadenado por hash y firmado, que puede exportar y verificar sin conexión con la clave pública de la pasarela.
- Cada llamada al proveedor, cada resultado y cada cambio de configuración, encadenados: un hueco o una corrección se nota.
- Cada aprobación: quién pidió, para qué, quién decidió y cuándo habría caducado.
- Trazas de OpenTelemetry para las ejecuciones de agentes, ingeridas desde su propio framework, de modo que la vista de la pasarela y la del agente son un único árbol.
- Con Enterprise, paquetes de evidencias de agentes: paquetes firmados con las ejecuciones, aprobaciones, paradas y el libro de los agentes de una organización, asignados al AI Act y a DORA.
Se ejecuta donde usted se ejecuta
Un binario de Rust en su propia infraestructura. Sin phone-home, con air-gap posible y Apache-2.0 para todo lo anterior salvo las tarjetas marcadas como Enterprise, las aprobaciones en Slack y Teams, los tokens del proveedor de identidad y de cargas de trabajo, la política de herramientas en respuestas pass-through, la inspección TLS y las reglas de herramientas para dispositivos. Los agentes alcanzan los modelos por un endpoint compatible con OpenAI, las herramientas por la pasarela MCP y otros agentes por la pasarela A2A — bajo la misma política, los mismos presupuestos y las mismas evidencias.
MCP y gobernanza de herramientas · Toda la plataforma · Comparación con LiteLLM
Ponga un plano de control delante de sus agentes
Ejecútelo en su propia infraestructura
Todo lo necesario para operar un control plane en producción es Apache-2.0 y seguirá siéndolo: enrutamiento, alta disponibilidad, caché, failover, presupuestos, políticas, MCP, trabajos y observabilidad. Self-hosted, sin cuenta, sin phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>No es un pull que funcione: las imágenes aún no son públicas. Los socios de diseño reciben los datos del registro en privado.
Despliega en 5 minutosContribuya a definirlo como design partner
Wäg todavía no se ha publicado. Trabajamos con un grupo reducido de equipos que ejecutan IA multiproveedor en producción y se toman en serio la gobernanza y la soberanía, para endurecer el control plane con cargas de trabajo reales.
- Todas las capacidades Enterprise incluidas, sin coste de licencia
- Migración acompañada: la hacemos con usted, también desde LiteLLM
- Línea directa con los ingenieros que lo construyen e influencia real sobre lo que llega después