AWS Connects Cross-Organization A2A Agents with Bidirectional OAuth

Summary:AWS has published a reference architecture for cross-organization agent collaboration using the Agent-to-Agent (A2A) protocol. A LangChain orchestrator running on Amazon ECS discovers and invokes a Strands agent deployed on Amazon Bedrock AgentCore through an Agent Card, while both sides authenticate through separate Cognito pools and support bidirectional OAuth-protected callbacks. The design isolates internal tools, prompts, models, and SDKs behind a protocol-level interface based on JSON-RPC

---

Cross-organization collaboration without shared frameworks or SDKs

AWS has published a reference architecture for cross-organization multi-agent collaboration based on the Agent-to-Agent (A2A) protocol. A LangChain orchestrator runs on Amazon ECS and Fargate, while a third-party compliance agent built with Strands Agents runs on Amazon Bedrock AgentCore. The two sides communicate through JSON-RPC over HTTPS without sharing frameworks, SDKs, secrets, or internal tool definitions.

This is not merely a client calling a server. The SaaS agent can call back into the enterprise context agent to retrieve production-account identifiers, internal policies, and escalation contacts before producing an enriched report. This peer-to-peer pattern handles a common distributed-systems constraint: the called agent may need context that only the caller owns, while still keeping its system prompt, tools, and model implementation private.

Agent Cards provide runtime discovery and tool mapping

Every agent publishes an Agent Card at /.well-known/agent-card.json. The document describes the agent's name, endpoint, protocol version, capabilities, skills, streaming support, and security requirements. At startup, the enterprise orchestrator reads these cards and converts each advertised skill into a LangChain tool. The LLM then selects a tool according to the user's request.

This removes much of the hard-coded routing found in conventional integrations. A vendor can publish a new skill and update its Agent Card; the orchestrator can rediscover that capability after a restart. Discovery, however, is not the same as trust. A production system should bind card URLs and security metadata to endpoints, issuers, clients, and scopes registered during onboarding.

The sample therefore pins the agent URL to the address obtained during discovery and does not follow HTTP redirects. The SaaS Agent Card exposes one curated compliance-scanning capability instead of revealing the three underlying tools. The vendor can consequently change its tools, prompts, or model without breaking the customer-facing contract.

A2A and MCP operate at different architectural layers

The design separates two protocol layers. MCP connects an agent to its own tools and data sources in a conventional client-server relationship. A2A connects agents across framework and organizational boundaries as peers.

A SaaS provider could use MCP internally to reach AWS Config, Security Hub, or GuardDuty, while exposing only an A2A interface to customers. This stabilizes the external contract, but it also adds work around protocol adaptation, error mapping, and identity propagation. The original user token should not simply be forwarded across the trust boundary; each direction should receive a separate least-privilege service token tied to a client, scope, and task identifier.

Bidirectional OAuth preserves separate trust domains

The sample uses two AWS accounts and two Amazon Cognito user pools. The enterprise orchestrator uses a token issued by the enterprise pool to call the SaaS agent. The SaaS agent uses a token from its own pool for the callback into the enterprise context API. The accounts exchange only public onboarding values such as issuer URLs, client IDs, scopes, and endpoints. They do not share client secrets.

Receiving endpoints validate the token's issuer, audience or client ID, scope, and allowed client. Cognito client-credentials access tokens may omit an aud claim. In that case, API Gateway checks client_id against its audience list, while AgentCore should use allowedClients without requiring an audience that the token does not contain.

The implementation fails closed: if no valid token can be obtained, it does not send the request. On a 401 response, it refreshes the token and retries once. This behavior is safer than indefinitely retrying a rejected credential, although it still requires monitoring to distinguish authorization failures from transient token-service failures.

End-to-end validation covers both behavior and trust boundaries

Three Jupyter notebooks perform enterprise onboarding, deploy the SaaS agent, deploy the enterprise services, and execute an end-to-end test. Together, they create five CloudFormation stacks. The workflow discovers the compliance agent, initiates a scan, invokes a callback for enterprise context, and returns both compliance findings and an on-call identifier available only inside the enterprise domain.

The test also sends missing, incorrect, and forged tokens. Seven combinations must be rejected with 401 responses. This is more meaningful than proving that the agents can exchange messages, because a common production failure in cross-organization systems is accepting a valid token at the wrong endpoint. The checks remain scenario-specific, however, and do not establish Agent Card supply-chain security, tenant-level data isolation, callback replay protection, or token-service behavior under high concurrency.

Cost, latency, and context overhead require planning

Always-on resources in the enterprise account include a NAT Gateway, two Fargate tasks, an internal Network Load Balancer, and two interface VPC endpoints, in addition to Bedrock and AgentCore usage charges. Two container services, internal load balancing, cross-account HTTPS, and multiple callback round trips introduce cold starts, network latency, and model inference time. The sample reports that end-to-end requests typically take one to three minutes; this should not be treated as a production concurrency SLA.

Agent Cards and skill descriptions also consume model context. As the number of advertised skills grows, tool-selection accuracy, prompt size, misrouting probability, and routing overhead can increase. Production deployments should cap the number of skills, review tool descriptions, validate card signatures where available, and combine deterministic policy checks with model-based selection.

Production checklist

• Run one runtime per customer or isolate tenants with per-customer OAuth clients and callback policies at a shared front door.
• Use AWS PrivateLink and in-VPC TLS for private cross-account connectivity.
• Protect S3, ECR, Secrets Manager, CloudWatch Logs, and Bedrock Guardrails with customer-managed KMS keys.
• Enable VPC Flow Logs, NLB access logs, and API Gateway access logs, then correlate callback and task IDs across services.
• Rotate Cognito credentials automatically and replace shared client secrets with private_key_jwt or mutual TLS.
• Add Agent Card validation, prompt-injection controls, callback replay protection, timeouts, circuit breakers, and an authenticated onboarding API.

The reference architecture demonstrates that A2A can compose cross-organization workflows without exposing internal implementation details. Its primary value is not a new model, but a protocol layer that separates discovery, invocation, callbacks, and authentication. Production adoption still requires stronger multi-tenant isolation, private networking, zero-secret-sharing patterns, complete auditability, and protection against protocol metadata manipulation.

---

Source: AWS Machine Learning Blog (2026-11-12)

— END —

Tags: #A2A Protocol Follow #Multi-Agent Systems Follow #OAuth Follow #Amazon Bedrock AgentCore Follow #LangChain Follow