Agent gateways: o control plane que seus agentes de IA em produção não devem negligenciar

Enquanto um agente de IA se limita a buscar informações ou redigir uma resposta, um erro permanece geralmente reversível. O risco muda de natureza quando ele pode modificar um banco de dados, disparar um pagamento, enviar um email, abrir um chamado ou chamar um serviço terceirizado.

Neste ponto, uma questão de arquitetura se torna central:

quem realmente decide se a ação proposta pelo modelo pode ser executada?

A resposta não pode repousar unicamente no prompt do agente. Um modelo probabilístico não deve ser o único responsável pela autorização de uma ação determinística.

É o papel do agent gateway: colocar uma camada de controle entre a intenção produzida pelo agente e sua execução no sistema real.

A AWS descreve agora seu AgentCore Gateway como uma camada de conectividade unificada entre agentes, suas ferramentas e seus recursos. Seu mecanismo de políticas pode interceptar solicitações e avaliar cada chamada antes de autorizar o acesso a uma ferramenta. O Google também apresenta seu Agent Gateway como um ponto central de aplicação de políticas para chamadas de ferramentas e comunicações agentivas. (AWS Documentation)

A categoria ainda está em construção. Nem todas as plataformas atribuem exatamente o mesmo escopo ao termo agent gateway. Mas a necessidade arquitetônica já é clara:

Assim que um agente pode produzir efeitos colaterais significativos, uma camada de controle determinística deve separar sua decisão da execução.

O que é um agent gateway?

Um agent gateway é um ponto de interceptação e aplicação de políticas colocado no caminho de execução das ações de um agente.

Seu papel não é tornar o modelo mais inteligente. Consiste em verificar que a ação proposta é autorizada, válida, rastreável e compatível com as restrições operacionais do sistema.

Um fluxo simplificado funciona assim:

1. O modelo propõe o uso de uma ferramenta com parâmetros estruturados.
2. O orquestrador transmite esse pedido ao gateway.
3. O gateway verifica identidade, permissões, parâmetros, quotas e regras de negócio.
4. A ação é autorizada, recusada ou suspensa aguardando validação humana.
5. O resultado da ferramenta é registrado e devolvido ao orquestrador.

No caso de ferramentas executadas no lado do cliente com Claude, o modelo não executa ele próprio o código de negócio. Ele retorna um bloco tool_use, e então a aplicação decide se deve executar a ferramenta e transmite seu resultado. Essa separação fornece precisamente o ponto de interceptação necessário para aplicação de políticas. (Claude Platform Docs)

Um agent gateway pode ser:

• um componente desenvolvido no orquestrador;
• um serviço independente;
• uma camada construída em volta de um API gateway existente;
• um policy engine conectado a servidores MCP;
• um serviço gerenciado fornecido por uma plataforma cloud.

O essencial não é, portanto, adquirir um produto chamado "Agent Gateway". O essencial é dispor de um ponto de enforcement impossível de contornar antes de qualquer ação sensível.

Por que prompts e permissões estáticas não são suficientes

Uma instrução como "nunca reembolse mais de 5.000 €" é útil para guiar o modelo. Não é uma regra de segurança.

Ela pode ser mal interpretada, contornada por injeção de prompt, perdida em um contexto muito longo ou ignorada após um erro de raciocínio.

O OWASP classifica a excessive agency entre os riscos maiores de aplicações baseadas em LLM: um modelo com funcionalidades, permissões ou autonomia excessivas pode provocar ações prejudiciais a partir de uma saída inesperada, ambígua ou manipulada. Seu guia dedicado a agentes recomenda especialmente o princípio do menor privilégio, validação independente de ações sensíveis e supervisão humana apropriada ao seu impacto. (OWASP Gen AI Security Project)

O problema não vem apenas de um agente "malévolo". Um agente pode provocar um incidente enquanto persegue corretamente seu objetivo:

• ele repete uma ação por má gestão de retries;
• ele interpreta incorretamente uma resposta de API;
• ele reutiliza informações do tenant errado;
• ele escolhe uma ferramenta muito poderosa para a operação solicitada;
• ele encadeia várias ações válidas produzindo coletivamente um resultado indesejado;
• ele aplica uma instrução injetada em um email, documento ou página web;
• ele continua uma operação quando a primeira etapa falhou parcialmente.

A proteção deve, portanto, situar-se fora do raciocínio do modelo, em uma camada capaz de aplicar regras determinísticas.

Os seis controles de um agente em produção

Um gateway sério não se resume a uma whitelist de ferramentas. Ele deve responder a seis questões.

1. Controle de identidade

Quem solicita a ação?

É necessário poder distinguir:

• o agente;
• a aplicação ou o workflow que o executa;
• o usuário final para o qual ele agisce;
• a organização ou o tenant em questão;
• a sessão;
• o nível de delegação concedido.

A identidade do agente não deve se limitar a um campo agent_id fornecido no payload. Ela deve ser atestada por um mecanismo de autenticação verificável.

O Google distingue, por exemplo, a identidade própria do agente e sua capacidade de agir por conta própria ou pela de um usuário. Seu sistema Agent Identity se baseia em uma identidade criptográfica e no padrão SPIFFE. (Google Cloud Documentation)

2. Controle de autorização

Este agente pode usar esta ferramenta neste contexto preciso?

A regra não deve apenas dizer:

agente-suporte -> acesso CRM

Ela deve poder expressar:

agente-suporte -> leitura de pedidos do tenant atual -> nenhuma exportação global -> nenhuma exclusão -> modificação limitada a certos campos

O princípio do menor privilégio deve se aplicar às ferramentas, operações, recursos e dados.

A AWS permite, por exemplo, associar um mecanismo de políticas a um gateway para avaliar chamadas de ferramentas antes de sua execução. As regras podem ser expressas como políticas determinísticas, especialmente com Cedar. (AWS Documentation)

3. Controle de parâmetros

A ação é permitida com estes parâmetros particulares?

Autorizar a ferramenta approve_refund não significa autorizar todos os reembolsos.

O gateway deve especialmente poder verificar:

• os valores;
• os destinatários;
• os identificadores de tenant;
• as tabelas ou colunas consultadas;
• os domínios acessíveis;
• os tipos e tamanhos de arquivo;
• as faixas de data;
• os esquemas de dados;
• os valores proibidos.

Esta validação deve ser determinística e idealmente baseada em esquemas rigorosos, não em uma segunda instrução em linguagem natural.

4. Controle comportamental

O comportamento global do agente permanece normal?

Uma chamada isolada pode ser válida enquanto a sequência completa não é.

O gateway deve poder detectar:

• loops;
• rajadas de chamadas;
• retries sem backoff;
• custos anormais;
• mudanças bruscas de ferramentas;
• uma sucessão incomum de ações;
• um volume de recusas revelando um agente bloqueado ou mal configurado.

Os rate limits e circuit breakers devem ser calculados por agente, usuário, tenant, ferramenta e tipo de ação, não apenas por endereço IP.

5. Controle de efeitos

A ação deve ser executada imediatamente?

Nem todas as ações apresentam o mesmo risco.

Uma política razoável pode distinguir:

• ações em leitura apenas;
• escritas reversíveis;
• ações externas visíveis por um terceiro;
• operações financeiras;
• exclusões;
• modificações de permissões;
• ações irreversíveis.

Para operações críticas, o gateway pode impor:

• validação humana;
• autenticação reforçada;
• confirmação do usuário;
• um mecanismo de dupla aprovação;
• uma simulação prévia;
• uma chave de idempotência;
• execução diferida.

Os mecanismos de aprovação propostos pelas plataformas de agentes seguem essa lógica. OpenAI prevê especialmente pausas e validações para chamadas que produzem efeitos colaterais ou consideradas destrutivas. (OpenAI Desenvolvedores)

6. Controle pós-execução

O que realmente aconteceu?

Autorizar uma ação não é suficiente. Também é necessário registrar:

• a solicitação inicial;
• a identidade e delegação;
• a política aplicada;
• a decisão do gateway;
• os parâmetros validados;
• a ferramenta chamada;
• a resposta da ferramenta;
• o estado final;
• eventuais erros ou compensações.

Este rastreamento permite reconstruir um incidente, medir o desempenho dos agentes e distinguir uma má decisão do modelo de uma falha do sistema externo.

O tracing do OpenAI Agents SDK registra, por exemplo, gerações, chamadas de ferramentas, handoffs, guardrails e eventos personalizados de um run. Essa observabilidade é útil, mas não substitui um journal de negócio durável e adaptado às obrigações da empresa. (OpenAI)

Onde colocar o gateway na arquitetura?

A representação correta não é necessariamente:

LLM -> gateway -> ferramenta

Em muitos sistemas, o modelo nunca contata diretamente a ferramenta. Ele produz uma proposta de chamada estruturada, e então o orquestrador decide o que fazer.

Uma arquitetura mais fiel se parece com isto:

┌────────────────────────┐
│ Usuário / evento       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Agent orchestrator     │
│ LangGraph, n8n, custom │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ LLM                    │
│ Proposta de tool call  │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ AGENT GATEWAY          │
│                        │
│ • identidade           │
│ • autorização          │
│ • validação            │
│ • quotas               │
│ • aprovação humana     │
│ • journaling           │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Tool executor          │
│ API, MCP, worker       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Sistema de negócio     │
│ CRM, DB, email, ERP    │
└────────────────────────┘

O gateway é assim um Policy Enforcement Point colocado antes do executor de ferramentas.

Deve ser impossível contornar esse ponto chamando diretamente:

• o banco de dados;
• um servidor MCP;
• a API de negócio;
• uma função cloud;
• um worker;
• um serviço terceirizado.

Um gateway que controla apenas um caminho de acesso enquanto o agente tem credenciais diretos para as ferramentas cria uma ilusão de segurança.

Agent gateway, API gateway e ai gateway: quais diferenças?

As três categorias se sobrepõem parcialmente, mas não respondem exatamente ao mesmo problema.

Um API gateway como Kong, Nginx ou um serviço cloud pode constituir parte da solução. Ele já sabe autenticar, limitar e registrar solicitações.

O que geralmente falta é o contexto agentivo e de negócio:

• qual agente está agindo;
• em nome de quem;
• qual intenção ou tarefa está em andamento;
• qual ferramenta está sendo invocada;
• que efeitos a ação pode produzir;
• qual política de negócio se aplica;
• uma aprovação humana é obrigatória;
• essa invocação faz parte de um loop anormal.

A abordagem correta não é necessariamente substituir o API gateway. Ele pode ser enriquecido ou complementado por uma camada de políticas dedicada aos agentes.

O Google define seu Agent Gateway como uma abstração de rede governando interações cliente-agente, agente-ferramenta e agente-agente, com aplicação de políticas de segurança e controle de acesso. (Google Cloud Documentation)

Três casos de uso concretos

Caso 1: um agente gerencia reembolsos de clientes

O agente analisa uma solicitação e propõe um reembolso.

Uma política de gateway poderia impor:

Valor ≤ 200 €:
    execução automática

200 € < valor ≤ 2.000 €:
    execução autorizada se a conta atender aos critérios de negócio

Valor > 2.000 €:
    validação humana obrigatória

Valor > 10.000 €:
    recusa automática para este workflow

A decisão do modelo permanece útil: ele pode qualificar o caso e propor um valor. Mas a autorização financeira é controlada por uma regra independente.

A AWS usa precisamente um cenário de processamento de reembolsos em sua documentação para mostrar como políticas podem limitar valores autorizados. (AWS Documentation)

Caso 2: um agente consulta dados sensíveis

Dar a um agente uma conexão SQL genérica raramente é uma boa ideia.

Uma arquitetura mais segura expõe ferramentas limitadas:

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

O gateway verifica então:

• que o usuário pode acessar o cliente solicitado;
• que o tenant corresponde à sessão;
• que apenas colunas autorizadas são retornadas;
• que dados pessoais desnecessários são mascarados;
• que a chamada permanece em leitura apenas;
• que o volume de dados é razoável.

O melhor controle de uma query SQL perigosa frequentemente permanece nunca dar ao modelo a capacidade de gerar SQL arbitrário.

Caso 3: um agente consome APIs pagas

Um agente pode gerar uma fatura importante sem que nenhuma chamada individual seja anormal.

O gateway pode aplicar vários orçamentos:

100 chamadas por minuto e por agente
1.000 chamadas por hora e por tenant
200 € por dia para o workflow
10 € máximo para uma execução individual

Acima de um limite, ele pode:

• desacelerar as chamadas;
• abrir um circuit breaker;
• fazer fallback para um modelo ou fornecedor menos custoso;
• suspender apenas a ferramenta em questão;
• solicitar validação;
• parar o run.

Uma implementação mínima

A primeira versão não precisa ser um produto autônomo. Um wrapper bem projetado ao redor do executor de ferramentas pode 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"

            # Use uma chave de idempotência para escritas que podem ser retentadas.
            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,
                # Não registre cegamente segredos ou dados pessoais.
                "params": self._redact(params),
                "approved_by": approved_by,
            })

Este código ilustra o princípio de interceptação. Não é um gateway pronto para produção.

Ainda faltam, dependendo do contexto:

• autenticação criptográfica;
• armazenamento distribuído para quotas;
• política de delegação;
• validação rigorosa de esquemas;
• gestão de segredos;
• redação de dados sensíveis;
• journals duráveis e protegidos;
• timeouts;
• retries limitados;
• mecanismos de compensação;
• alta disponibilidade;
• procedimentos de revogação;
• proteção contra acessos diretos a ferramentas.

Roadmap de implementação

Fase 1: inventariar ações e reduzir permissões

Antes de desenvolver um gateway, liste todas as ferramentas acessíveis aos agentes.

Para cada ferramenta, documente:

• recursos acessíveis;
• operações possíveis;
• efeitos colaterais;
• caráter reversível ou irreversível;
• dados sensíveis expostos;
• custo potencial;
• nível de aprovação necessário.

Comece então com:

• remover ferramentas desnecessárias;
• separar leitura e escrita;
• substituir ferramentas genéricas por operações de negócio limitadas;
• adicionar validação de esquema;
• registrar chamadas e seus resultados.

Fase 2: centralizar políticas

Adicione um contexto de execução estruturado:

• identidade do agente;
• usuário;
• tenant;
• run;
• objetivo do workflow;
• nível de risco;
• delegação ativa.

Em seguida, centralize:

• regras de autorização;
• limites de valor;
• quotas;
• aprovações;
• restrições temporais;
• regras de dados;
• circuit breakers.

Fase 3: industrializar

Quando várias equipes, agentes ou ambientes usam as mesmas ferramentas, transforme a camada em um serviço compartilhado.

Adicione:

• um policy engine;
• gestão centralizada de identidades;
• um registro de agentes e ferramentas;
• políticas versionadas;
• traces correlados;
• alertas;
• testes de políticas;
• modo de observação sem bloqueio;
• procedimento de incidente;
• controles de conformidade.

O NIST AI Risk Management Framework recomenda identificar funções necessitando supervisão humana, definir papéis e responsabilidades e adaptar mecanismos de controle ao contexto e nível de risco. (NIST)

Os erros de implementação mais frequentes

1. Controlar o nome da ferramenta, mas não seus parâmetros

Uma whitelist que autoriza send_email sem verificar destinatário, domínio, conteúdo ou volume fornece proteção limitada.

Uma autorização útil diz respeito a:

agente + usuário + tenant + ferramenta + operação + recurso + parâmetros

2. Deixar um caminho de contorno

Se o workflow puder chamar diretamente o CRM ou o banco de dados, o gateway não é um ponto de enforcement.

As credenciais dos sistemas de negócio devem ser mantidas pelo executor controlado, não expostas diretamente ao modelo ou a um worker alternativo.

3. Registrar apenas a solicitação

Uma ação pode ser autorizada e depois falhar parcialmente.

É necessário registrar:

• a decisão;
• o início da execução;
• o resultado;
• os retries;
• o estado final;
• compensações eventuais.

Para sistemas assíncronos, use um identificador de correlação comum entre o run do agente, a invocação, o job e o evento de negócio.

4. Registrar segredos nos traces

As ferramentas frequentemente manipulam tokens, dados pessoais, informações financeiras ou conteúdos de clientes.

Um audit trail útil não significa registrar a integralidade de parâmetros e respostas sem filtragem. A redação e as regras de retenção devem ser projetadas desde o início.

5. Aplicar os mesmos limites a todas as ações

Cem leituras de catálogo e cem transferências não apresentam o mesmo risco.

As políticas devem depender de:

• da ferramenta;
• do impacto;
• do tenant;
• do valor financeiro;
• do caráter reversível;
• da confiança acordada ao workflow.

6. Bloquear sem informar o orquestrador

Quando uma ação é recusada, o agente deve receber um erro utilizável:

{
  "code": "HUMAN_APPROVAL_REQUIRED",
  "message": "Reembolsos acima de 2.000 EUR requerem aprovação.",
  "retryable": false
}

Uma resposta vaga como Access denied frequentemente leva o agente a repetir a mesma ação.

7. Confundir observabilidade com autorização

Rastrear uma chamada não a impede de ser executada.

O rastreamento ajuda a compreender. O gateway também deve ser capaz de:

• autorizar;
• recusar;
• modificar;
• suspender;
• solicitar aprovação;
• abrir um circuit breaker.

Gateway caseiro ou solução especializada?

O número de agentes não é o critério correto.

Um único agente capaz de fazer transferências pode justificar uma infraestrutura robusta. Cinquenta agentes em leitura apenas sobre dados públicos podem permanecer atrás de um wrapper relativamente simples.

A decisão deve depender da criticidade.

Comece internamente quando:

• você tem poucas ferramentas;
• workflows são dominados;
• regras são simples;
• você já tem infraestrutura sólida de IAM e observabilidade;
• a camada pode permanecer próxima à aplicação.

Industrialize ou compre quando:

• múltiplas equipes duplicam os mesmos controles;
• políticas devem ser centralizadas;
• agentes usam múltiplos runtimes;
• servidores MCP e ferramentas se multiplicam;
• obrigações de audit se tornam importantes;
• manter as regras se torna carga cognitiva ou operacional.

Como saber se seu agente precisa de um gateway?

Atribua um ponto para cada resposta positiva:

• O agente escreve em um sistema de negócio?
• Pode ele apagar ou tornar públicos dados?
• Manipula dados pessoais ou confidenciais?
• Pode ele gastar dinheiro?
• Pode ele contatar um cliente ou terceiro?
• Ele tem múltiplas ferramentas?
• Age para múltiplos usuários ou tenants?
• Uma ação pode ser irreversível?
• Um erro pode gerar um incidente regulatório?
• O workflow funciona sem supervisão humana direta?

Interpretação

• 0 a 2 pontos: um wrapper simples, permissões limitadas e logs podem ser suficientes.
• 3 a 5 pontos: implemente um ponto de enforcement explícito e políticas versionadas.
• 6 ou mais pontos: trate o gateway como um componente crítico da sua arquitetura.

Esta grade não é uma norma. Serve para evitar decisão baseada apenas em tamanho de projeto ou número de agentes.

Conclusão

Um agent gateway não é um proxy mágico que automaticamente securiza um sistema agentivo.

É um princípio de arquitetura:

a decisão probabilística do modelo nunca deve constituir sozinha a autorização de uma ação real.

Assim que um agente produz efeitos colaterais, você deve dispor de um ponto de controle capaz de verificar sua identidade, delegação, permissões, parâmetros, comportamento e impacto da ação.

Três princípios devem ser lembrados:

1. O prompt guia; a política autoriza.
   Uma instrução em linguagem natural não substitui uma regra determinística.

2. O controle deve ser impossível de contornar.
   Todos os acessos sensíveis devem passar pelo mesmo ponto de enforcement.

3. O nível de controle depende do impacto, não do número de agentes.
   Um agente único pode necessitar governança forte se manipula pagamentos, permissões ou dados sensíveis.

Você não necessariamente precisa de uma plataforma especializada desde o primeiro protótipo. Mas você deve definir muito cedo onde fica a fronteira entre o que o agente propõe e o que seu 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],
    })