Everything you need to know
about the Agent Gateway

No. Federation works against your existing AgentCore and AI Foundry deployments. Agents continue to run where they already are — Jarvis Registry imports their metadata into the local catalog and proxies invocations through the gateway, applying RBAC and ACL policies on top of the existing deployment. There is no agent-side code change required.

Jarvis Registry connects to your AgentCore deployment using cross-account IAM role assumption. Once configured, Jarvis performs an on-demand sync to discover all agents in the target AgentCore workspace. Discovered agents appear in the registry catalog and are immediately subject to your RBAC and ACL governance policies. Copilots invoke them through the same Jarvis gateway endpoint as every native agent — the federation source is transparent to the client.

Jarvis Registry connects to Azure AI Foundry using your tenant credentials, scoped to the subscription and resource group you specify. Synced agents are imported into the local catalog and governed by the same identity and access policies as all other registered agents — RBAC scopes, per-user ACLs, and audit logging apply uniformly regardless of whether an agent runs in Azure, AWS, or on-premises.

Jarvis Registry supports two distinct orchestration models.

Manual drag-and-drop pipeline: a visual canvas where you connect registered agents in sequence or parallel to define a deterministic workflow. This is best for compliance-sensitive processes where every step must be auditable and predictable.

LLM-driven orchestration: you define a curated pool of permitted agents and provide a task. An LLM reasons over the task, selects the appropriate agents from the pool, and sequences execution dynamically. The LLM operates only within the approved agent pool, so governance is maintained without constraining the model reasoning.

Both models share the same governance layer, observability pipeline, and security posture.

Yes. You can define a pipeline where certain stages are deterministic — a fixed agent sequence or a human approval gate — and others delegate to an LLM sub-orchestrator over a defined agent pool. This lets you enforce strict control at sensitive steps while giving the LLM flexibility over intermediate processing where determinism is less critical.

Every agent published to the registry passes through an automated security scan before it can be invoked.

The scan covers prompt injection patterns in system prompts and capability declarations, capability misuse risks where agents declare access to tools or data beyond their intended scope, and policy compliance against custom rules you define per environment.

The scan acts as a publish gate — an agent cannot be invoked until it passes. Re-scan triggers automatically whenever an agent card is updated, ensuring no previously approved agent can silently introduce a risk through an update.

Jarvis Registry integrates with your enterprise identity provider such as Azure EntraID, Okta, or Auth0 via OIDC and SAML.

Access is governed at two levels: RBAC scopes that control which agents a user or group can discover and invoke, and ACL policies that provide per-agent access control lists for specific users, teams, or service identities.

Both layers apply uniformly to native agents, AWS AgentCore-federated agents, and Azure AI Foundry-federated agents. A user only sees and can invoke what they are explicitly authorized for, regardless of where the agent runs.

No. Jarvis Registry is licensed, customer-hosted software that deploys into your own Kubernetes environment such as AWS EKS, Azure AKS, or GKE. All agent metadata, access control policies, audit logs, and invocation telemetry remain inside your infrastructure. There is no external data plane and no shared cloud service that receives your data.

The integrated OpenTelemetry collector instruments every layer of the agent gateway without requiring any changes to your agents.

It captures distributed traces from copilot request through gateway routing to agent response, invocation metrics such as latency, error rates, token usage, and throughput per agent, per user, and per team, workflow execution events for both manual and LLM-driven pipelines, and access decisions including denials for compliance reporting.

All telemetry exports via OTLP to any compatible backend, including Datadog, Grafana, Honeycomb, AWS CloudWatch, Azure Monitor, or self-hosted stacks like Jaeger and Prometheus.

Yes. Every agent invocation, workflow step, tool call, and access decision is logged. Audit logs are stored within your environment and can be integrated with your existing logging and SIEM tooling. This supports compliance requirements across regulated industries including finance, healthcare, and government.

Logs are retained inside the registry independently of any OTLP export destination, so compliance reporting is available even before you connect an observability backend.

Jarvis Registry works with any MCP-compatible AI client. This includes Claude Desktop, Claude Code, VS Code, Cursor, GitHub Copilot, Microsoft Copilot, Windsurf, Jarvis Chat, and ChatGPT. One registry, every client — no duplicate configuration required per tool or per team.

The two products are fully independent and can be used separately. Jarvis Registry is the agent gateway and catalog — it serves any MCP-compatible copilot. Jarvis Chat is a governed multi-LLM chat workspace for enterprise teams.

When used together they form a complete enterprise AI platform: Jarvis Chat connects to Jarvis Registry to discover and invoke agents, while Registry simultaneously serves Microsoft Copilot, Claude, VS Code, and any other client your teams use. Neither product requires the other.