Agent gateways: el control plane que tus agentes IA en producción no deben ignorar

Mientras un agente IA se limite a buscar información o redactar una respuesta, un error suele ser reversible. La naturaleza del riesgo cambia cuando puede modificar una base de datos, desencadenar un pago, enviar un email, abrir un ticket o llamar a un servicio tercero.

En este punto, una cuestión arquitectónica se vuelve central:

¿quién decide realmente si la acción propuesta por el modelo puede ejecutarse?

La respuesta no puede basarse únicamente en el prompt del agente. Un modelo probabilístico no debe ser el único responsable de autorizar una acción determinista.

Este es el rol del agent gateway: colocar una capa de control entre la intención producida por el agente y su ejecución en el sistema real.

AWS ahora describe su AgentCore Gateway como una capa de conectividad unificada entre los agentes, sus herramientas y sus recursos. Su motor de políticas puede interceptar solicitudes y evaluar cada llamada antes de autorizar el acceso a una herramienta. Google también presenta su Agent Gateway como un punto central de aplicación de políticas para las llamadas de herramientas y las comunicaciones agentícas. (AWS Documentation)

La categoría sigue en construcción. No todas las plataformas dan exactamente el mismo alcance al término agent gateway. Pero la necesidad arquitectónica ya es clara:

Cuando un agente puede producir efectos secundarios significativos, una capa de control determinista debe separar su decisión de la ejecución.

¿Qué es un agent gateway?

Un agent gateway es un punto de interceptación y aplicación de políticas colocado en la ruta de ejecución de las acciones de un agente.

Su rol no es hacer más inteligente el modelo. Consiste en verificar que la acción propuesta está autorizada, es válida, es trazable y es compatible con las restricciones operacionales del sistema.

Un flujo simplificado funciona así:

1. El modelo propone el uso de una herramienta con parámetros estructurados.
2. El orquestador transmite esta solicitud al gateway.
3. El gateway verifica la identidad, los permisos, los parámetros, las cuotas y las reglas de negocio.
4. La acción se autoriza, se rechaza o se suspende en espera de validación humana.
5. El resultado de la herramienta se registra y se devuelve al orquestador.

En el caso de herramientas ejecutadas del lado del cliente con Claude, el modelo no ejecuta él mismo el código de negocio. Devuelve un bloque tool_use, y luego la aplicación decide si ejecutar o no la herramienta y le transmite su resultado. Esta separación proporciona precisamente el punto de interceptación necesario para la aplicación de políticas. (Claude Platform Docs)

Un agent gateway puede ser:

• un componente desarrollado en el orquestador;
• un servicio independiente;
• una capa construida sobre un API gateway existente;
• un motor de políticas conectado a servidores MCP;
• un servicio gestionado proporcionado por una plataforma cloud.

Lo esencial no es comprar un producto llamado «Agent Gateway». Lo esencial es disponer de un punto de aplicación no evitable antes de cualquier acción sensible.

Por qué los prompts y los permisos estáticos no son suficientes

Una instrucción como «nunca reembolsar más de 5.000 €» es útil para guiar el modelo. No es una regla de seguridad.

Puede ser mal interpretada, eludida mediante inyección de prompts, perdida en un contexto demasiado largo o ignorada después de un error de razonamiento.

OWASP clasifica la excessive agency entre los riesgos principales de aplicaciones basadas en LLM: un modelo con funcionalidades, permisos o autonomía excesivos puede provocar acciones dañinas a partir de una salida inesperada, ambigua o manipulada. Su guía dedicada a agentes recomienda en particular el principio del menor privilegio, la validación independiente de acciones sensibles y la supervisión humana apropiada a su impacto. (OWASP Gen AI Security Project)

El problema no proviene solo de un agente «malicioso». Un agente puede causar un incidente mientras persigue correctamente su objetivo:

• repite una acción debido a una mala gestión de reintentos;
• interpreta incorrectamente una respuesta de API;
• reutiliza información del tenant equivocado;
• elige una herramienta demasiado poderosa para la operación solicitada;
• encadena múltiples acciones válidas que producen colectivamente un resultado no deseado;
• aplica una instrucción inyectada en un email, documento o página web;
• continúa una operación cuando el primer paso ha fallado parcialmente.

La protección debe situarse fuera del razonamiento del modelo, en una capa capaz de aplicar reglas deterministas.

Los seis controles de un agente en producción

Un gateway serio no se reduce a una whitelist de herramientas. Debe responder a seis preguntas.

1. Control de identidad

¿Quién solicita la acción?

Debe ser posible distinguir:

• el agente;
• la aplicación o el workflow que lo ejecuta;
• el usuario final para el que actúa;
• la organización o el tenant implicado;
• la sesión;
• el nivel de delegación otorgado.

La identidad del agente no debe limitarse a un campo agent_id proporcionado en el payload. Debe estar atestiguada por un mecanismo de autenticación verificable.

Google, por ejemplo, distingue la identidad propia del agente y su capacidad para actuar por su propia cuenta o en nombre de un usuario. Su sistema Agent Identity se basa en una identidad criptográfica y en el estándar SPIFFE. (Google Cloud Documentation)

2. Control de autorización

¿Puede este agente usar esta herramienta en este contexto específico?

La regla no debe solo decir:

support-agent -> acceso CRM

Debe poder expresar:

support-agent -> lectura de órdenes del tenant actual -> ninguna exportación global -> ninguna eliminación -> modificación limitada a ciertos campos

El principio del menor privilegio debe aplicarse a las herramientas, las operaciones, los recursos y los datos.

AWS permite, por ejemplo, asociar un motor de políticas a un gateway para evaluar llamadas de herramientas antes de su ejecución. Las reglas pueden expresarse como políticas deterministas, en particular con Cedar. (AWS Documentation)

3. Control de parámetros

¿Se permite la acción con estos parámetros particulares?

Autorizar la herramienta approve_refund no significa autorizar todos los reembolsos.

El gateway debe poder verificar en particular:

• los montos;
• los destinatarios;
• los identificadores de tenant;
• las tablas o columnas interrogadas;
• los dominios accesibles;
• los tipos y tamaños de archivo;
• los rangos de fechas;
• los esquemas de datos;
• los valores prohibidos.

Esta validación debe ser determinista e idealmente basada en esquemas estrictos, no en una segunda instrucción en lenguaje natural.

4. Control conductual

¿El comportamiento global del agente sigue siendo normal?

Una llamada aislada puede ser válida mientras que la secuencia completa no lo es.

El gateway debe poder detectar:

• bucles;
• ráfagas de llamadas;
• reintentos sin backoff;
• costos anormales;
• cambios bruscos de herramientas;
• una sucesión inusual de acciones;
• un volumen de rechazos que revela un agente atrapado o mal configurado.

Los rate limits y circuit breakers deben calcularse por agente, usuario, tenant, herramienta y tipo de acción, no solo por dirección IP.

5. Control de efectos

¿Debe la acción ejecutarse inmediatamente?

No todas las acciones presentan el mismo riesgo.

Una política razonable puede distinguir:

• acciones de solo lectura;
• escrituras reversibles;
• acciones externas visibles por terceros;
• operaciones financieras;
• eliminaciones;
• modificaciones de permisos;
• acciones irreversibles.

Para operaciones críticas, el gateway puede imponer:

• validación humana;
• autenticación reforzada;
• confirmación del usuario;
• un mecanismo de doble aprobación;
• una simulación previa;
• una clave de idempotencia;
• una ejecución diferida.

Los mecanismos de aprobación propuestos por plataformas de agentes siguen esta lógica. OpenAI prevé en particular pausas y validaciones para llamadas que producen efectos secundarios o se consideran destructivas. (OpenAI Developers)

6. Control posterior a la ejecución

¿Qué sucedió realmente?

Autorizar una acción no es suficiente. También debe registrarse:

• la solicitud inicial;
• la identidad y delegación;
• la política aplicada;
• la decisión del gateway;
• los parámetros validados;
• la herramienta llamada;
• la respuesta de la herramienta;
• el estado final;
• los eventuales errores o compensaciones.

Este rastreo permite reconstruir un incidente, medir el rendimiento de los agentes y distinguir una mala decisión del modelo de una falla del sistema externo.

El tracing del SDK de OpenAI Agents, por ejemplo, registra generaciones, llamadas de herramientas, handoffs, guardrails y eventos personalizados de una ejecución. Esta observabilidad es útil, pero no reemplaza un registro comercial duradero y adaptado a las obligaciones de la empresa. (OpenAI)

¿Dónde colocar el gateway en la arquitectura?

La representación correcta no es necesariamente:

LLM -> gateway -> herramienta

En muchos sistemas, el modelo nunca contacta directamente la herramienta. Produce una propuesta de llamada estructurada, y luego el orquestador decide qué sigue.

Una arquitectura más fiel se parece a esto:

┌────────────────────────┐
│ Usuario / evento       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Orquestador de agentes │
│ LangGraph, n8n, custom │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ LLM                    │
│ Propuesta de tool call │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ AGENT GATEWAY          │
│                        │
│ • identidad            │
│ • autorización         │
│ • validación           │
│ • cuotas               │
│ • aprobación humana    │
│ • registro             │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Ejecutor de herramientas│
│ API, MCP, worker       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Sistema de negocio     │
│ CRM, BD, email, ERP    │
└────────────────────────┘

El gateway es, por lo tanto, un Policy Enforcement Point colocado antes del ejecutor de herramientas.

Debe ser imposible eludir este punto llamando directamente a:

• la base de datos;
• un servidor MCP;
• la API de negocio;
• una función cloud;
• un worker;
• un servicio tercero.

Un gateway que solo controla una ruta de acceso mientras el agente tiene credenciales directas a las herramientas crea una ilusión de seguridad.

Agent gateway, API gateway e IA gateway: ¿cuáles son las diferencias?

Las tres categorías se superponen parcialmente, pero no responden exactamente al mismo problema.

Un API gateway como Kong, Nginx o un servicio cloud puede constituir parte de la solución. Ya sabe autenticar, limitar y registrar solicitudes.

Lo que generalmente falta es el contexto agentícco y de negocio:

• qué agente actúa;
• en nombre de quién;
• qué intención o tarea está en curso;
• qué herramienta se invoca;
• qué efectos puede producir la acción;
• qué política de negocio se aplica;
• ¿se requiere aprobación humana?
• ¿esta invocación forma parte de un bucle anormal?

El mejor enfoque no es necesariamente reemplazar el API gateway. Puede enriquecerse o completarse con una capa de políticas dedicada a los agentes.

Google define su Agent Gateway como una abstracción de red que gobierna las interacciones cliente-agente, agente-herramienta y agente-agente, con aplicación de políticas de seguridad y control de acceso. (Google Cloud Documentation)

Tres casos de uso concretos

Caso 1: un agente gestiona reembolsos de clientes

El agente analiza una solicitud y propone un reembolso.

Una política de gateway podría imponer:

Monto ≤ 200 €:
    ejecución automática

200 € < monto ≤ 2.000 €:
    ejecución autorizada si la cuenta cumple criterios de negocio

Monto > 2.000 €:
    validación humana obligatoria

Monto > 10.000 €:
    rechazo automático para este workflow

La decisión del modelo sigue siendo útil: puede calificar el caso y proponer un monto. Pero la autorización financiera se controla mediante una regla independiente.

AWS utiliza precisamente un escenario de procesamiento de reembolsos en su documentación para mostrar cómo las políticas pueden limitar los montos autorizados. (AWS Documentation)

Caso 2: un agente consulta datos sensibles

Dar a un agente una conexión SQL genérica rara vez es una buena idea.

Una arquitectura más segura expone herramientas estrechas:

get_customer_orders(customer_id)
get_order_status(order_id)
get_monthly_sales_summary(period)

El gateway entonces verifica:

• que el usuario puede acceder al cliente solicitado;
• que el tenant coincida con la sesión;
• que solo se devuelven las columnas autorizadas;
• que los PII innecesarios están enmascarados;
• que la llamada permanece en solo lectura;
• que el volumen de datos es razonable.

El mejor control de una consulta SQL peligrosa sigue siendo a menudo no dar al modelo la capacidad de generar SQL arbitrario.

Caso 3: un agente consume APIs pagadas

Un agente puede generar una factura importante sin que ninguna llamada individual sea anormal.

El gateway puede aplicar varios presupuestos:

100 llamadas por minuto y por agente
1.000 llamadas por hora y por tenant
200 € por día para el workflow
10 € máximo para una ejecución individual

Más allá de un umbral, puede:

• ralentizar las llamadas;
• abrir un circuit breaker;
• cambiar a un modelo o proveedor menos costoso;
• suspender solo la herramienta concernida;
• solicitar una validación;
• detener la ejecución.

Una implementación mínima

La primera versión no necesita ser un producto autónomo. Un wrapper bien diseñado alrededor del ejecutor de herramientas puede ser suficiente.

from dataclasses import dataclass
from datetime import datetime, timezone
from decimal import Decimal
from typing import Any, Callable


class GatewayDenied(Exception):
    pass


@dataclass(frozen=True)
class InvocationContext:
    agent_id: str
    user_id: str
    tenant_id: str
    run_id: str


@dataclass(frozen=True)
class ToolPolicy:
    handler: Callable[..., Any]
    write_operation: bool = False
    max_amount: Decimal | None = None
    requires_approval: bool = False


class AgentGateway:
    def __init__(self, policies: dict[str, ToolPolicy], audit_sink):
        self.policies = policies
        self.audit_sink = audit_sink

    def invoke(
        self,
        context: InvocationContext,
        tool_name: str,
        params: dict[str, Any],
        approved_by: str | None = None,
    ) -> Any:
        started_at = datetime.now(timezone.utc)
        decision = "denied"
        result_status = "not_executed"

        try:
            policy = self.policies.get(tool_name)

            if policy is None:
                raise GatewayDenied("Tool not allowed")

            self._verify_identity(context)
            self._check_rate_limits(context, tool_name)
            self._validate_schema(tool_name, params)
            self._enforce_tenant_scope(context, params)

            if policy.max_amount is not None:
                amount = Decimal(str(params.get("amount", 0)))

                if amount > policy.max_amount:
                    raise GatewayDenied("Amount exceeds policy limit")

            if policy.requires_approval and approved_by is None:
                raise GatewayDenied("Human approval required")

            decision = "allowed"

            # Usar una clave de idempotencia para escrituras reintentables.
            result = policy.handler(
                **params,
                tenant_id=context.tenant_id,
                idempotency_key=f"{context.run_id}:{tool_name}",
            )

            result_status = "succeeded"
            return result

        except Exception:
            result_status = "failed"
            raise

        finally:
            self.audit_sink.write({
                "timestamp": started_at.isoformat(),
                "agent_id": context.agent_id,
                "user_id": context.user_id,
                "tenant_id": context.tenant_id,
                "run_id": context.run_id,
                "tool": tool_name,
                "decision": decision,
                "result_status": result_status,
                # No registrar ciegamente secretos o PII.
                "params": self._redact(params),
                "approved_by": approved_by,
            })

Este código ilustra el principio de interceptación. No es un gateway listo para producción.

Todavía falta, dependiendo del contexto:

• autenticación criptográfica;
• almacenamiento distribuido para cuotas;
• una política de delegación;
• validación estricta de esquemas;
• gestión de secretos;
• redacción de datos sensibles;
• registros duraderos y protegidos;
• timeouts;
• reintentos acotados;
• mecanismos de compensación;
• alta disponibilidad;
• procedimientos de revocación;
• protección contra accesos directos a herramientas.

Roadmap de implementación

Fase 1: inventariar acciones y reducir permisos

Antes de desarrollar un gateway, liste todas las herramientas accesibles para los agentes.

Para cada herramienta, documente:

• los recursos accesibles;
• las operaciones posibles;
• los efectos secundarios;
• el carácter reversible o irreversible;
• los datos sensibles expuestos;
• el costo potencial;
• el nivel de aprobación necesario.

Luego comience con:

• eliminar herramientas innecesarias;
• separar lectura y escritura;
• reemplazar herramientas genéricas con operaciones de negocio estrechas;
• añadir validación de esquema;
• registrar llamadas y sus resultados.

Fase 2: centralizar políticas

Añada un contexto de ejecución estructurado:

• identidad del agente;
• usuario;
• tenant;
• ejecución;
• objetivo del workflow;
• nivel de riesgo;
• delegación activa.

Luego centralice:

• reglas de autorización;
• límites de monto;
• cuotas;
• aprobaciones;
• restricciones temporales;
• reglas de datos;
• circuit breakers.

Fase 3: industrializar

Cuando múltiples equipos, agentes o entornos usan las mismas herramientas, transforme la capa en un servicio compartido.

Añada:

• un motor de políticas;
• gestión centralizada de identidades;
• un registro de agentes y herramientas;
• políticas versionadas;
• trazas correlacionadas;
• alertas;
• pruebas de políticas;
• modo de observación sin bloqueo;
• procedimiento de incidente;
• controles de cumplimiento.

El Marco de Gestión de Riesgos de IA del NIST recomienda identificar funciones que requieren supervisión humana, definir roles y responsabilidades y adaptar mecanismos de control al contexto y nivel de riesgo. (NIST)

Los errores de implementación más frecuentes

1. Controlar el nombre de la herramienta, pero no sus parámetros

Una whitelist que autoriza send_email sin verificar destinatario, dominio, contenido o volumen solo aporta protección limitada.

Una autorización útil se aplica a:

agente + usuario + tenant + herramienta + operación + recurso + parámetros

2. Dejar una ruta de contornamiento

Si el workflow puede llamar directamente al CRM o a la base de datos, el gateway no es un punto de aplicación.

Las credenciales de sistemas de negocio deben ser retenidas por el ejecutor controlado, no expuestas directamente al modelo o a un worker alternativo.

3. Registrar solo la solicitud

Una acción puede autorizarse y luego fallar parcialmente.

Debe registrarse:

• la decisión;
• el inicio de ejecución;
• el resultado;
• los reintentos;
• el estado final;
• las compensaciones eventuales.

Para sistemas asincronos, use un identificador de correlación común entre la ejecución del agente, la invocación, el job y el evento de negocio.

4. Registrar secretos en trazas

Las herramientas a menudo manipulan tokens, PII, datos financieros o contenidos de clientes.

Un registro de auditoría útil no significa registrar íntegramente parámetros y respuestas sin filtrado. La redacción y las reglas de retención deben diseñarse desde el inicio.

5. Aplicar los mismos límites a todas las acciones

Cien lecturas de catálogo y cien transferencias no presentan el mismo riesgo.

Las políticas deben depender de:

• la herramienta;
• el impacto;
• el tenant;
• el valor financiero;
• el carácter reversible;
• la confianza otorgada al workflow.

6. Bloquear sin informar al orquestador

Cuando se rechaza una acción, el agente debe recibir un error explotable:

{
  "code": "HUMAN_APPROVAL_REQUIRED",
  "message": "Reembolsos superiores a 2000 EUR requieren aprobación.",
  "retryable": false
}

Una respuesta vaga como Acceso denegado a menudo impulsa al agente a repetir la misma acción.

7. Confundir observabilidad con autorización

Rastrear una llamada no la impide ejecutarse.

El rastreo ayuda a comprender. El gateway también debe poder:

• autorizar;
• rechazar;
• modificar;
• suspender;
• solicitar aprobación;
• abrir un circuit breaker.

¿Gateway casero o solución especializada?

El número de agentes no es el criterio correcto.

Un único agente capaz de realizar transferencias puede justificar una infraestructura fuerte. Cincuenta agentes en solo lectura sobre datos públicos pueden permanecer detrás de un wrapper relativamente simple.

La decisión debe depender de la criticidad.

Comience en interno cuando:

• tiene pocas herramientas;
• los workflows están bajo control;
• las reglas son simples;
• ya tiene una infraestructura IAM y de observabilidad sólida;
• la capa puede permanecer cercana a la aplicación.

Industrialice o compre cuando:

• múltiples equipos duplican los mismos controles;
• las políticas deben centralizarse;
• los agentes usan múltiples runtimes;
• los servidores MCP y herramientas se multiplican;
• las obligaciones de auditoría se vuelven importantes;
• mantener las reglas se convierte en una carga cognitiva u operacional.

¿Cómo saber si su agente necesita un gateway?

Asigne un punto por cada respuesta afirmativa:

• ¿Escribe el agente en un sistema de negocio?
• ¿Puede eliminar o hacer públicos datos?
• ¿Manipula datos personales o confidenciales?
• ¿Puede incurrir en gastos?
• ¿Puede contactar a un cliente o tercero?
• ¿Dispone de múltiples herramientas?
• ¿Actúa para múltiples usuarios o tenants?
• ¿Puede una acción ser irreversible?
• ¿Puede un error producir un incidente regulatorio?
• ¿Funciona el workflow sin supervisión humana directa?

Interpretación

• 0 a 2 puntos: un wrapper simple, permisos estrechos y logs pueden ser suficientes.
• 3 a 5 puntos: implemente un punto de aplicación explícito y políticas versionadas.
• 6 puntos o más: trate el gateway como un componente crítico de su arquitectura.

Esta grilla no es una norma. Sirve para evitar una decisión basada únicamente en el tamaño del proyecto o el número de agentes.

Conclusión

Un agent gateway no es un proxy mágico que asegure automáticamente un sistema agentícco.

Es un principio de arquitectura:

la decisión probabilística del modelo nunca debe constituir por sí sola la autorización de una acción real.

Cuando un agente produce efectos secundarios, debe disponer de un punto de control capaz de verificar su identidad, delegación, permisos, parámetros, comportamiento e impacto de la acción.

Tres principios a recordar:

1. El prompt guía; la política autoriza.
   Una instrucción en lenguaje natural no reemplaza una regla determinista.

2. El control debe ser no evitable.
   Todos los accesos sensibles deben pasar por el mismo punto de aplicación.

3. El nivel de control depende del impacto, no del número de agentes.
   Un agente único puede requerir una gobernanza fuerte si manipula pagos, permisos o datos sensibles.

No necesariamente necesita una plataforma especializada desde el primer prototipo. Pero debe definir muy temprano dónde se encuentra la frontera entre lo que el agente propone y lo que su sistema realmente autoriza.

response = client.messages.create(
    model=MODEL_NAME,
    max_tokens=1024,
    tools=tool_definitions,
    messages=messages,
)

for block in response.content:
    if block.type != "tool_use":
        continue

    try:
        result = gateway.invoke(
            context=invocation_context,
            tool_name=block.name,
            params=block.input,
        )

        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "content": serialize_result(result),
        }

    except GatewayDenied as exc:
        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "is_error": True,
            "content": str(exc),
        }

    messages.append({
        "role": "assistant",
        "content": response.content,
    })

    messages.append({
        "role": "user",
        "content": [tool_result],
    })