Cómo Obolo protege a los agentes conectados
Obolo se sienta entre tu agente y los servidores MCP de terceros. Ese lugar en medio es donde aplicamos los controles: bloqueo de destinos internos, detección de cambios de esquema, topes de gasto y niveles de verificación. Abajo, qué hace cada uno y qué no.
Panorama
El principio es simple: un agente no debería tener que confiar ciegamente en un servidor MCP que encontró en un directorio. Obolo convierte "confiá y esperá" en controles concretos que corren en cada llamada, antes de que la respuesta del upstream llegue al agente.
Protección SSRF
En las llamadas salientes hacia upstreams, el gateway bloquea destinos de red privada. Un servidor MCP comprometido o malicioso no puede usar a Obolo para llegar a metadatos de la nube, servicios internos o direcciones de loopback. Se resuelve y valida el destino para cortar el rebinding de DNS, no sólo la primera resolución.
Detección de drift / rug-pull
Cada manifiesto se reduce a un hash canónico estable. Si un servidor cambia sus herramientas sin avisar — un rug-pull de esquema — el hash cambia y Obolo lo detecta antes de que ese esquema alterado llegue a un agente conectado. La verificación de nivel 2 se apoya en ese hash.
Topes de gasto + corte 429
Cada key tiene un tope de gasto duro contra un saldo prepago. Cuando el gasto alcanza el límite, el gateway corta con 429 en lugar de seguir cobrando. Es la defensa contra un agente en loop o un servidor que intenta inflar el uso: el daño máximo está acotado por adelantado.
Niveles de verificación como señal
El nivel es la etiqueta de confianza que el agente ve antes de gastar. "crawled" (nivel 1) es sólo metadatos indexados de un directorio público. "verified" (nivel 2) significa que el publisher probó titularidad vía DNS y registro y que el esquema pasó el análisis estático con hash canónico. Un operador puede exigir sólo nivel 2.
Merchant of record + auditoría
Obolo es el merchant of record: cobra al comprador y liquida al publisher. Cada llamada de herramienta queda en un registro de auditoría — qué servidor, qué herramienta, cuánto costó — de modo que el gasto es reconstruible y disputable, no una caja negra.
Preguntas frecuentes
La verificación es estática: prueba de titularidad (DNS + registro), análisis del esquema declarado y hash canónico. No ejecuta el servidor para verificarlo. Cuando sí se ejecuta un servidor stdio ajeno para descubrir sus herramientas, corre en un sandbox aislado con egress restringido por allowlist; no es la ruta por la que pasan las credenciales ni las llamadas de producción.
El gateway bloquea destinos de red privada en las llamadas salientes (protección SSRF) y valida el destino resuelto para frenar el rebinding de DNS. Un servidor no puede usar a Obolo como pivote hacia metadatos de la nube, servicios internos o loopback.
El manifiesto tiene un hash canónico. Un cambio no declarado altera el hash, Obolo detecta el drift y ese esquema alterado no se sirve a los agentes conectados como si fuera el verificado.
Reportar una vulnerabilidad
Si encontrás un problema de seguridad, escribinos antes de divulgarlo públicamente. Respondemos a reportes de buena fe: hola@obolo.dev