Jarvis connects them - to every copilot, every team, and every cloud. Federate AgentCore and Azure AI Foundry agents under one governed endpoint — 2 clouds, 1 access policy, deployed inside your own environment without touching a single agent.
AWS AgentCore and Azure AI Foundry are purpose-built for agent hosting and execution. What it doesn't provide is an experience and access layer for the rest of your organization - across clouds, teams, and copilots.
Agents from AgentCore or AI Foundry are not natively reachable from Claude Desktop, Cursor, or VS Code. Every copilot requires direct AWS credential configuration - no governed endpoint in between.
AgentCore access is controlled by AWS IAM. If you also run agents in Azure AI Foundry, each cloud enforces its own access model - no unified identity-bound policy across clouds.
Governance gapAgentCore agents live inside AWS. Azure Foundry agents live inside Azure. Copilots and orchestration pipelines have no single governed namespace to discover or invoke them.
Discovery problemAgentCore agents are not natively reachable from Claude Desktop, Cursor, or VS Code. Every copilot requires direct AWS credential configuration - no governed endpoint in between.
Experience gapJarvis Agent Gateway runs inside your own environment - on AWS, Azure, or on-premises Kubernetes. It federates agents from AgentCore and Azure AI Foundry into a unified governed catalog, then exposes them to every copilot through one authenticated endpoint.
Claude DesktopClaude Code
VS Code
Cursor
GitHub Copilot
MS Copilot
Windsurf
Custom AppsA dedicated experience layer between AgentCore/AI Foundry and the rest of your AI stack - with multi-cloud catalog, unified governance, and agent orchestration built in.
AgentCore agents and Azure AI Foundry agents exist in the same governed namespace. One registration, one access policy, one audit trail - regardless of which cloud hosts the agent. Adding a new cloud source doesn't change anything for the consuming copilots.
AgentCore + Azure AI FoundryJarvis federates both AgentCore agents (A2A protocol) and MCP tool servers into the same catalog. Copilots get a single endpoint that resolves both - no separate MCP server config, no separate agent endpoint per team.
MCP & Agent RegistryInstead of maintaining per-team IAM policies inside AWS and separate Foundry roles inside Azure, enterprise access is modeled once in Jarvis using your IdP identities - Entra ID, Okta, or Auth0. Scoped RBAC roles and per-agent ACL policies apply uniformly across both clouds.
AgentCore RBAC & ACLCopilots authenticate to Jarvis via OAuth 2.0. Jarvis proxies to AgentCore using ephemeral STS tokens scoped to each request. No AWS credentials are distributed to developer machines, no credential rotation per team, no leaked IAM keys in copilot config files.
Zero-Trust AccessOne MCP endpoint URL in each developer's copilot config gives access to all permitted AgentCore and Foundry agents. When your team deploys a new agent to AgentCore, it appears automatically on the next catalog sync - no client-side change, no re-announcement to teams.
AgentCore Access LayerFederated AgentCore agents are first-class participants in Jarvis Workflow - the agent orchestration layer. Build multi-step pipelines that chain AgentCore agents with Azure Foundry agents and native A2A agents, with full audit and supervised or autonomous execution modes.
Agent OrchestrationSee Jarvis connect AWS AgentCore and Azure AI Foundry into one governed experience layer - live demo, your environment.
Most enterprises end up with agents in more than one cloud, and the cost is not the runtime — it is the duplicated governance. Agent federation puts AWS AgentCore and Azure AI Foundry agents in 1 catalog under 1 policy model. These 6 rows summarise how agent federation works in practice.
| Aspect | How federation works |
|---|---|
| Runtimes covered | AWS AgentCore and Azure AI Foundry, federated side by side into a single catalog namespace. |
| Migration required | None. Agents keep their existing runtime, deployment pipeline, and release cadence in their home cloud. |
| Identity | Azure EntraID authenticates the caller once; the gateway then presents the right credential to each cloud. |
| Access policy | A single ACL model spans both clouds, so a team’s permissions do not have to be restated per provider. |
| Client integration | Copilots integrate with 1 endpoint instead of 2 provider SDKs, which is what removes the duplicated wiring. |
| Audit | Cross-cloud invocations land in 1 trace, so an A2A chain that crosses providers is still readable end to end. |
Federation is judged on 3 questions: what stays put, what is exchanged at the boundary, and what the audit trail records. The rows below answer all 3 with the standards that define each mechanism.
| Specification | Value |
|---|---|
| Federated runtimes | 2 — AWS AgentCore and Azure AI Foundry |
| Agents redeployed | 0 — each agent stays in its home runtime and pipeline |
| Catalog namespaces | 1 shared namespace spanning both clouds |
| Client credentials held | 1 set — the caller authenticates once against Azure EntraID |
| Credential exchange | OAuth 2.0 Token Exchange (RFC 8693) at the boundary |
| Base authorization | OAuth 2.0 (RFC 6749), Bearer usage per RFC 6750 |
| Token scoping | Resource Indicators for OAuth 2.0 (RFC 8707) |
| Token format | JSON Web Token (RFC 7519) |
| Identity federation | OpenID Connect Core 1.0 and SAML 2.0 |
| Transport security | TLS 1.3 (RFC 8446) preferred, TLS 1.2 minimum |
| Agent protocol | A2A invocation; MCP (JSON-RPC 2.0) for tool calls |
| Cross-cloud trace | 1 trace per chain — a 3-hop workflow spanning both clouds stays 1 record |
| Telemetry format | OpenTelemetry OTLP |
| Zero-trust model | NIST SP 800-207 (2020), evaluated per request |
| Runtimes | 3 managed Kubernetes services — Amazon EKS, Azure AKS, Google GKE |
| Vendor data plane | 0 — the registry runs inside the customer account |
A recorded walkthrough of AgentCore agents being registered and invoked through Jarvis, which is the concrete version of the federation architecture described above.
Agent federation is configuration rather than migration, which is why it can usually be completed without involving the teams that own the individual agents. These 5 steps are the working order.
Inventory both clouds. List the AgentCore and AI Foundry agents already in production and note which teams depend on each.
Deploy Jarvis Registry. Stand the registry up in an existing Kubernetes cluster; it is the neutral ground both clouds register into.
Connect the providers. Attach AWS AgentCore and Azure AI Foundry so their agents appear in the catalog without being redeployed.
Unify the policy model. Map existing per-cloud permissions onto one ACL scheme so entitlements stop drifting between providers.
Repoint the clients. Switch copilots from provider SDKs to the gateway endpoint and confirm cross-cloud calls appear in 1 trace.
The value of federation shows up in the audit view: a workflow that touches agents in both providers reads as a single chain rather than two disconnected halves.
Multi-cloud agent estates raise a predictable set of concerns about lock-in, latency, and credential handling. These are the answers that matter during an architecture review.
Agents remain deployed in AWS AgentCore and Azure AI Foundry throughout, so removing the registry leaves both estates exactly as they were before federation.
The integration surface clients use is MCP, an open protocol, rather than a proprietary API — which is the practical test of whether a gateway is reversible.
The caller authenticates once against Azure EntraID. The gateway then presents the correct credential to whichever provider hosts the target agent, so client code never holds 2 sets of cloud credentials.
Because credentials terminate at the gateway rather than in the client, rotating a provider credential does not require redeploying every copilot integration.
It stays a single logical chain. Each hop records the invoking agent, the target, and the policy version in force, regardless of which provider hosted which step.
That is the main operational reason to federate: without it, a 3-hop workflow spanning both clouds produces 2 partial audit trails and no end-to-end view.
No. Agents keep whatever definition format their home runtime uses; the registry catalogs them and applies a common access policy on top.
Standardising definitions is a reasonable goal, but federation does not depend on it and should not be blocked waiting for it.
Federation is a capability of the Agent Gateway. These pages cover the gateway, the catalog, and the wider governance model.
ASCENDING is an AWS Advanced Tier Services Partner with the AWS Generative AI Competency, and builds Jarvis as licensed software that runs inside your own cloud account. The documents below are the primary sources for the runtimes and protocols involved.
