Como a Uber protege seus agentes de IA em produção

A Uber parte de uma tese simples: autorização tradicional diz quem pode agir, mas não diz se a ação proposta faz sentido para o que o usuário pediu. Quando um agente de IA lê conteúdo de usuários, páginas, documentos, ferramentas e outros agentes, parte da superfície de ataque migra para a camada semântica. Entram aí prompt injection, tool and memory poisoning, goal hijacking, behavioral drift e ações causadas por alucinação. O caso mais difícil que a empresa descreve é o agente manipulado a fazer algo indevido mesmo com usuário, agente, ferramenta e cada chamada de API legitimamente autorizados.

O framework, chamado Uber Secure AI, tem três camadas. No provisionamento, o Uber AI Registry guarda identidade, dono, persona, intents permitidos, constraints, dependências e nível de risco do agente. O Argus analisa código-fonte, prompts, configurações, dependências, endpoints e caminhos de invocação de ferramentas, e deriva intents da implementação para comparar com o que foi declarado. Servidores MCP de terceiros passam por análise estática e dinâmica, software composition analysis e inspeção semântica das descrições. Em runtime, o modelo clássico de PAP, PDP e PEP é estendido: o AI Registry é o PAP, o AI Guard é o PDP, e o Agent Guard, com LangFx ou o AI Guard SDK, atua como PEP. Na terceira camada, traces unificados, replay contra novos guardrails, threat modeling automatizado e red teaming contínuo realimentam políticas e risk scores.

O assunto se conecta a uma sequência de textos da própria Uber no CEVIU. Em 2 de outubro de 2026, o CEVIU noticiou "Uber Aprimora Segurança com Novo Sistema de Identidade para Agentes de IA", sobre o limite do modelo de identidade original, que não previa agentes agindo em nome de usuários. Agora a empresa mostra a camada acima disso: com identidade resolvida, o foco passa a ser governar o comportamento do agente, e não só o acesso. É uma leitura de continuidade entre os dois textos, não uma afirmação da fonte.

Para quem constrói agentes, a leitura é que checar permissão de API não basta. Vale desenhar persona, intents e constraints desde o início e medir falsos bloqueios em shadow mode antes de impor a regra. A escolha de modelos pequenos e locais, com verificações em paralelo, também sugere que latência e custo precisam entrar no projeto do guardrail, não ficar para depois.