Dois dias depois de a SAP ser lida como "o porteiro que bloqueia o agente externo", a notícia é a outra metade do movimento: a SAP liberou, em disponibilidade geral, a interoperabilidade A2A inbound. Um agente de terceiro agora invoca um agente SAP pelo Agent Gateway (na SAP Business AI Platform). Mas não é "abrir a porta e sair de perto". É governed-open: aberto, porém com crachá, cofre e lista.
A frase que resume o espírito é da própria SAP: "descoberta não concede permissão de invocar um agente". Traduzindo para quem vai operar: encontrar o agente é só o primeiro passo; antes de uma única chamada passar, há três formações de segurança para montar — e uma assimetria importante para cobrir.
O que a SAP liberou: A2A inbound GA no Agent Gateway (e o que ainda é roadmap)
O fluxo é inbound: um agente externo descobre e invoca um agente SAP. A descoberta usa a spec aberta ARD (Agentic Resource Discovery) — cada resultado traz identificador, AgentCard e metadados. A invocação passa pelo Agent Gateway, que valida o token, resolve o tenant, checa a autorização e executa o agente dentro das autorizações de negócio do usuário logado, com log e auditoria, sem expor os sistemas SAP diretamente.
Há uma assimetria deliberada: por ora é inbound-only. O outbound A2A (um agente SAP delegar tarefa a um agente de fora) e o MCP (um agente SAP usar ferramentas externas) ficaram no roadmap. Quem está desenhando a arquitetura agora precisa projetar para esse descompasso.
Governed-open em 3 formações: Identity → Trust → Authorization
O onboarding de um agente externo como consumer do Agent Gateway passa por três etapas SAP-managed, em sequência:
- Identity. Um OIDC Agent Identity single-tenant, provisionado via SAP Cloud Identity Services. É o crachá: o agente externo ganha uma identidade verificável.
- Trust. A confiança entre essa identidade e o Agent Gateway. É o cofre: só identidades confiadas chegam ao gateway.
- Authorization. Uma ACL com os agentes permitidos e o que cada um pode invocar. É a lista: descoberta não concede permissão; a ACL concede.
É por isso que "descoberta não concede permissão de invocar" não é uma frase de efeito — é a arquitetura. Encontrar um AgentCard via ARD não autoriza nada; a autorização é uma decisão explícita, registrada na ACL, validada a cada chamada.
A assimetria inbound/outbound: o que fazer enquanto o outbound não chega
Enquanto o agente SAP não pode chamar um agente de fora (outbound) nem usar ferramentas externas via MCP, as tarefas que exigem esse sentido precisam ser resolvidas por fora — tipicamente por uma camada de integração que orquestra o fluxo e "simula" o que o protocolo ainda não entrega nativamente. Projetar para a assimetria hoje evita retrabalho quando o outbound/MCP sair: a camada que você monta agora deve ser a mesma que absorve o outbound amanhã, sem reescrever o encanamento.
O alcance SAP ↔ não-SAP: onde a tarefa real termina
O A2A inbound resolve o agente externo entrando na SAP. Mas a tarefa real raramente fica dentro da SAP: ela cruza e-commerce, OMS, fiscal/NF-e e legado. É aqui que o governed-open encontra seu limite natural — o gateway governa a entrada, não o percurso completo. Manter o alcance SAP ↔ não-SAP, com identidade e rastro consistentes dos dois lados da fronteira, é trabalho de arquitetura de integração, não um recurso do Agent Gateway.
Como a CCX faz: acesso governado + identidade + alcance ao não-SAP
"Governado e aberto" é bom — e dá trabalho. É exatamente o tipo de trabalho que a CCX faz. Com Integrações & APIs Enterprise e MuleSoft, montamos o acesso A2A inbound governado (registrar o cliente externo como Agent Gateway Consumer, roteamento, ACL por agente) e mantemos o alcance SAP ↔ não-SAP (e-commerce, OMS, fiscal), com arquitetura event-driven (Kafka/RabbitMQ) para os fluxos que transbordam da plataforma.
Com Security Engineering & Cybersecurity cuidamos da formação Identity/Trust/ACL — OIDC Agent Identity, escopo, OAuth2, SIEM, Vault e auditoria do agente externo. E com Consultoria em Tecnologia decidimos quais agentes SAP expor, com que escopo, e desenhamos para a assimetria inbound/outbound — para que a camada de hoje absorva o outbound/MCP de amanhã sem reescrever nada.
A SAP abriu o A2A inbound (GA) — mas é crachá (Agent Identity OIDC), cofre (trust) e lista (ACL), e outbound/MCP ainda são roadmap. A CCX monta o acesso governado (Agent Gateway + ACL por agente), a formação de identidade do agente externo e o alcance SAP ↔ não-SAP (e-commerce, OMS, fiscal) — e desenha para a assimetria enquanto o outbound não chega. Integre SAP ao seu e-commerce com a CCX →
O contraponto do dia: fechar-e-governar vs abrir-e-cobrar
No mesmo mês, duas gigantes tomaram caminhos opostos de abertura. A Salesforce põe a interop na vitrine e cobra por ação; a SAP abre o A2A inbound atrás de crachá, cofre e lista. Uma monetiza o acesso, a outra o condiciona a identidade e autorização. Mas a conclusão para quem integra é idêntica nas duas: quem desenhou a camada de integração e identidade decide se o agente externo vira produtividade ou vira risco. O protocolo padronizou o encaixe; a operação segura continua sendo engenharia sua, não importa de que lado da porta você esteja.
Na prática, montar o acesso inbound governado não é um clique. É registrar o cliente externo como Agent Gateway Consumer, provisionar a OIDC Agent Identity no Cloud Identity Services, estabelecer o trust, escrever a ACL agente a agente, e validar que cada chamada roda dentro das autorizações de negócio do usuário certo — com log e auditoria utilizáveis depois. Fazer isso errado não gera um erro barulhento; gera uma porta entreaberta. Fazer certo é o que separa "aberto e governado" de "aberto e exposto".
Perguntas frequentes
O A2A inbound é seguro? O modelo é forte por desenho: identidade OIDC, trust explícito, ACL por agente e execução dentro das autorizações do usuário logado, com auditoria. A segurança efetiva depende de montar as três formações corretamente — é aí que erros acontecem.
O ARD expõe meus dados? O ARD expõe a descoberta (quais agentes existem e o que fazem), não a permissão de invocar nem os dados. "Descoberta não concede permissão."
Preciso de MuleSoft para isso? Você precisa de uma camada de integração que registre o consumer, roteie, aplique ACL e estenda ao não-SAP. MuleSoft (API-led) é a forma que a CCX usa para isso de ponta a ponta.
E quando sai o outbound/MCP? Está no roadmap, sem data firme. O certo é projetar hoje uma camada que absorva o outbound quando chegar, sem retrabalho.