MCP Gateway
Provides the client-facing endpoint for discovering and invoking permitted MCP servers.
Explore MCP GatewayEnterprise Agent Gateway for Governed A2A Access
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.
Choose the right control point
Where the Agent Gateway Fits in Jarvis Registry
The Agent Gateway handles runtime agent-to-agent access. Registries maintain the records that make agents and MCP servers discoverable and governable.
MCP Server Registry
Catalogs MCP server endpoints, transports, metadata, and sharing settings as part of Jarvis Registry.
Explore Jarvis RegistryAgent Gateway
Provides the runtime entry point for governed agent-to-agent interactions.
Explore Agent GatewayAgent Registry
Catalogs agent ownership, capabilities, and lifecycle information.
Explore Agent RegistrySkill Gateway
Manages and distributes approved skills as an adjacent Registry capability.
Explore Skill GatewayGoverned AI
Provides cross-cutting governance context for identity, privacy, and observability across AI workloads.
Explore Governed AIComponents
What's Inside the Agent Gateway
Five core components validate agent identity, apply policy, route requests, and record observability data for governed A2A access.
A2A Agent Registry
Central catalog for autonomous agents. Each agent is registered by URL with skills, capabilities, and metadata auto-discovered via the A2A protocol.
MCP Server Registry
Companion catalog for MCP servers exposing tools, resources, and prompts. Combined with the agent catalog into a single governed namespace.
Federation Layer
Cross-cloud federation engine that imports agents from AWS AgentCore and Azure AI Foundry into the local catalog without redeployment.
Identity & Access Layer
IdP-driven authentication (Azure EntraID, Okta, Auth0) with RBAC scopes and per-resource ACL policies. Every access decision is identity-bound and audit-logged.
Unified Gateway Endpoint
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.
Multi-Cloud Federation
One Governed Runtime Across AWS and Azure
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.
☁ AWS AgentCore
AWS AgentCore Federation
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.
- ✓Cross-account IAM via assume-role for secure agent discovery
- ✓Automatic catalog sync brings AgentCore agents into the registry
- ✓Inherited governance same RBAC, ACL, and audit trail as native agents
- ✓No redeployment agents continue running in AgentCore
◈ Azure AI Foundry
Azure AI Foundry Federation
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.
- ✓Tenant-scoped discovery across subscriptions and resource groups
- ✓Unified catalog Azure agents alongside AWS and native A2A agents
- ✓Cross-cloud RBAC applied uniformly regardless of agent origin
- ✓One endpoint for copilots, regardless of which cloud hosts the agent
Features
Enterprise-Grade Agent Gateway Capabilities
Everything you need to authenticate, route, govern, and observe agent-to-agent access across your enterprise.
01—Copilot Integration
Interact With Agents From Every AI Copilot
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.
02—Agentic Orchestration
Two Models of Agentic Workflow
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.
03—Security & Compliance
Security Scanning at Publish Time
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.
04—Observability
Built-in OTEL Collector for Event Tracking
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.
Integrations
Works With Your Favorite AI Copilots
Jarvis Registry acts as the universal agent gateway — connecting any AI client to every registered and federated agent.
Claude Desktop
Chat Copilot
Claude Code
Coding Copilot
VS Code
IDE
Cursor
IDE
GitHub Copilot
Coding Copilot
Microsoft Copilot
Enterprise Copilot
Windsurf
IDE
Jarvis Chat
Chat Copilot
ChatGPT
Chat Copilot
Custom Clients
Custom App
Ready to Govern Your Enterprise AI Agents?
See how Jarvis Registry brings order to your agent ecosystem with enterprise-grade governance, multi-cloud federation, and observability.
At a glance
Agent Gateway
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. |
Specifications
Agent Gateway technical
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 |
Watch
Azure AI Foundry federation
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.
Rollout
How to put the gateway in front of your agents
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.
In practice
Governed agents in practice
Registration turns a scattered collection of cloud agents into a catalog with identity, policy, and an audit trail attached to every invocation.
FAQ
Agent Gateway questions we are asked most
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.
Related resources
Jarvis resources
The Agent Gateway is one half of Jarvis Registry. These pages cover the other half, the catalog beneath it, and the platform around it.
- Agent Gateway FAQ the full question set on registration, federation, and observability.
- AgentCore and AI Foundry federation how the 2 cloud agent runtimes are federated into 1 catalog.
- Agent Registry versioning, deprecation, and lifecycle management for registered agents.
- MCP Gateway the tool-side counterpart covering MCP discovery and OAuth scoping.
- Governed AI overview how identity, privacy, and observability combine across the platform.
Sources
Standards and references
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.
- Amazon Bedrock Agents documentation the AWS-side runtime federated into the catalog.
- Model Context Protocol (MCP) the standard clients use to discover and invoke registered agents.
- NIST SP 800-207 — Zero Trust Architecture the per-request authorisation model behind agent access policy.
- OpenTelemetry specification the trace format the built-in collector emits.
ASCENDING empowers businesses with AI-driven solutions and cloud transformation strategies. Unlock innovation, scalability, and efficiency with our expert services in AI, cloud migration, and digital modernization.