Route and govern agent-to-agent access across AWS AgentCore and Azure AI Foundry. Apply identity, policy, and observability through one customer-controlled gateway; keep ownership, approval, and lifecycle records in the Agent Registry.
Five core components validate agent identity, apply policy, route requests, and record observability data for governed A2A access.
Central catalog for autonomous agents. Each agent is registered by URL with skills, capabilities, and metadata auto-discovered via the A2A protocol.
Companion catalog for MCP servers exposing tools, resources, and prompts. Combined with the agent catalog into a single governed namespace.
Cross-cloud federation engine that imports agents from AWS AgentCore and Azure AI Foundry into the local catalog without redeployment.
IdP-driven authentication (Azure EntraID, Okta, Auth0) with RBAC scopes and per-resource ACL policies. Every access decision is identity-bound and audit-logged.
One authenticated endpoint that routes copilot requests to the right registered or federated agent — automatic auth elicitation, path proxying, and zero client-side routing logic.
Agents deployed in AWS AgentCore and Azure AI Foundry are imported into Jarvis Registry, governed under your access policies, and exposed through a single endpoint — no redeployment, no duplicated infrastructure.
Unify agents deployed in Amazon Bedrock AgentCore with the rest of your enterprise agent catalog. Federated agents inherit Jarvis Registry's governance — RBAC, ACL policies, audit trails, and observability — while continuing to run inside AgentCore.
Bring Foundry-hosted agents into the same governed catalog as your AWS-native and self-hosted agents. Jarvis handles discovery, lifecycle sync, and access control across the Azure tenant boundary — admins manage everything from one console.
Everything you need to authenticate, route, govern, and observe agent-to-agent access across your enterprise.
Every registered agent is reachable from all major AI copilots and IDEs through a single authenticated endpoint. No per-tool configuration, no duplicated access management — one URL that works everywhere your team already works.
Build agent pipelines your way — visual drag-and-drop for deterministic, audit-friendly workflows, or LLM-driven dynamic orchestration over a curated agent pool. Both share the same governance, observability, and security posture.
Every agent published to the registry passes through automated security scanning before it can be invoked. Guard against prompt injection, capability misuse, and unvetted third-party agents entering your production catalog. Re-scan triggers on every agent card update — no shadow AI, ever.
An integrated OpenTelemetry collector instruments every layer of the agent gateway — invocations, workflow steps, federation syncs, and access decisions — without requiring changes to your agents. Ship traces, metrics, and audit logs to Datadog, Grafana, Honeycomb, or any OTLP-compatible backend.
Jarvis Registry acts as the universal agent gateway — connecting any AI client to every registered and federated agent.
See how Jarvis Registry brings order to your agent ecosystem with enterprise-grade governance, multi-cloud federation, and observability.
The Agent Gateway is the half of Jarvis Registry that registers, secures, and routes enterprise AI agents across clouds. These 6 rows cover the architecture facts that decide whether it fits an existing agent estate.
| Aspect | What the Agent Gateway provides |
|---|---|
| Federation | AWS AgentCore and Azure AI Foundry agents are registered where they already run — 2 clouds, 1 catalog, no redeploy. |
| Registration checks | Every agent is security-scanned at registration before it becomes invocable from any client. |
| Routing | Context-aware invocation routing picks the correct agent version and target for each call. |
| Agent-to-agent calls | A2A invocations carry their own OAuth client credentials, with permitted targets declared per agent in ACL policy. |
| Client reach | Any MCP-compatible client — Microsoft Copilot, Claude, VS Code, Cursor — through 1 governed endpoint. |
| Telemetry | A built-in OpenTelemetry collector records each hop, the policy version in force, and the resulting decision. |
These are the interoperability facts that decide whether the gateway fits an existing agent estate. Every standards row cites the document that defines it, so the claim can be verified independently of this page.
| Specification | Value |
|---|---|
| Agent invocation | A2A over HTTPS, with each agent holding its own OAuth 2.0 client credentials |
| Tool invocation | Model Context Protocol (MCP) over JSON-RPC 2.0 |
| Authorization | OAuth 2.0 (RFC 6749); Bearer usage per RFC 6750 |
| Delegation | OAuth 2.0 Token Exchange (RFC 8693) for cross-cloud calls |
| Public-client flows | PKCE (RFC 7636) required for interactive copilots |
| Identity federation | OpenID Connect Core 1.0 and SAML 2.0 |
| Transport security | TLS 1.2 minimum, TLS 1.3 preferred (RFC 8446) |
| Federated clouds | 2 — AWS AgentCore and Azure AI Foundry, 1 shared catalog namespace |
| Redeploys required | 0 — registration is a catalog operation on agents already running |
| Registration gate | 1 security scan per agent version, run before the entry becomes invocable |
| Client coverage | 6 named MCP clients: Microsoft Copilot, GitHub Copilot, ChatGPT, Claude Desktop, VS Code, Cursor |
| Telemetry | OpenTelemetry OTLP — 1 span per hop, tagged with the policy version in force |
| Denial responses | HTTP 401 unauthenticated, HTTP 403 policy denial, HTTP 429 rate limited |
| Zero-trust model | NIST SP 800-207 (2020) |
| Runtimes | 3 managed Kubernetes services — Amazon EKS, Azure AKS, Google GKE |
| Customer rating | 5 out of 5 from 1 verified AWS Marketplace review |
A 3-minute walkthrough of the second half of the federation story: Azure AI Foundry agents registered into the same catalog as AWS AgentCore agents, reachable from any copilot through 1 governed endpoint.
Because the gateway federates rather than migrates, existing cloud agents keep their runtime and release process. These 5 steps take a team from an empty catalog to a governed, observable integration.
Deploy Jarvis Registry. Install into an existing Kubernetes cluster on Amazon EKS, Azure AKS, or Google GKE inside your own account.
Federate the clouds. Connect AWS AgentCore and Azure AI Foundry so their agents surface in 1 catalog without being redeployed.
Scan and register. Register each agent and review its security scan result before the entry is exposed to any client.
Declare access policy. Set the ACL entry for each agent, including which other agents it may invoke in an A2A chain.
Connect clients, then watch the traces. Point copilots at the gateway and use the OTEL output to confirm routing and policy behave as designed.
Registration turns a scattered collection of cloud agents into a catalog with identity, policy, and an audit trail attached to every invocation.
The questions below come up in nearly every architecture review, and the answers are the ones that determine whether a rollout is a configuration change or a migration.
No. Agents stay in the runtime that already hosts them. Registration is a catalog operation, so an AgentCore agent keeps running on AgentCore and an AI Foundry agent keeps running on AI Foundry.
What changes is the path callers take to reach them: instead of each client integrating with each cloud, every client goes through 1 governed endpoint.
The scan validates the agent definition against your organisation’s standards before the entry becomes invocable, so an unreviewed agent is never reachable from a copilot or another agent.
Because the check runs at registration rather than at call time, it adds no latency to invocations once an agent is live.
Each agent that can invoke others carries its own OAuth client credentials, and the agents it is permitted to call are listed explicitly in its ACL entry.
An orchestrator agent might be allowed to call a diagnosis agent and a remediation agent but not a billing agent, even when all 4 sit in the same catalog namespace.
Every hop records the invoking identity, the target agent, the tools called, and the policy version in effect at that moment, giving end-to-end traceability for multi-agent workflows.
No instrumentation is added to the agent code itself — the trace is produced by the gateway, so coverage does not depend on individual teams adopting a logging library.
The Agent Gateway is one half of Jarvis Registry. These pages cover the other half, the catalog beneath it, and the platform around it.
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. These are the primary specifications the gateway implements.
