MCP Gateway
Provides the client-facing endpoint for discovering and invoking permitted MCP servers.
Explore MCP GatewayEnterprise AI Agent Registry for Lifecycle Governance
Catalog A2A agents with an owner, capabilities, access policy, approval state, version, and deprecation path. Jarvis Agent Registry keeps lifecycle records authoritative while the Agent Gateway enforces access at runtime.
Choose the right control point
Where the Agent Registry Fits in Jarvis Registry
The Agent Registry owns agent catalog and lifecycle records. The gateways use those records to expose and route permitted runtime requests.
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 Registry
Six core components catalog each enterprise agent's owner, capabilities, approval state, version, lifecycle, and policy so the gateway can enforce the current record.
A2A Agent Registry
Central registry for autonomous agents. Each agent is cataloged with identity, owner team, skills, and capability schema — auto-discovered via the A2A protocol.
MCP Server Registry
Companion registry for MCP servers exposing tools, resources, and prompts. Merged with the agent registry into a single governed namespace accessible through one endpoint.
Federation Layer
Imports agents from AWS AgentCore and Azure AI Foundry into the local catalog without redeployment. Federated agents inherit the same RBAC, ACL policies, and audit trail as native agents.
Identity & Access Layer
Defines which orchestrators, workflows, users, and teams may invoke each registered agent. Policy objects live in the registry and propagate to the gateway in real time — no sync delay.
Audit Foundation
Every invocation record written by the gateway is anchored to the registry's version and policy state at that moment. The audit trail is self-contained — no post-hoc reconciliation required.
Version & Lifecycle Manager
Promote, deprecate, and retire agent versions with a single registry operation. Deprecation propagates to the gateway immediately — no workflow redeploys, no manual config changes.
Features
Enterprise-Grade Registry Capabilities
Everything you need to catalog, govern, and operate AI agents and MCP servers at enterprise scale.
01—Agent Catalog
One Catalog for Every Agent and MCP Server in Your Enterprise
A2A agents and MCP servers in a single governed namespace
Owner team, contact, and capability schema per registration
Search and discover before registering duplicates
Deprecation propagates to gateway routing immediately
02—Access Policy
Define Who Can Invoke What — Enforced at the Gateway
RBAC scopes and per-resource ACL policies
IdP-driven authentication via Azure EntraID, Okta, Auth0
Policy changes propagate to gateway enforcement in real time
Every access decision is identity-bound and audit-logged
03—Security & Compliance
Security Scanning at Registration — Before Anything Reaches Production
Publish gate — agents inactive until scan passes
Prompt injection detection on capability declarations
Policy compliance check before catalog entry
Auto re-scan on every agent card update
04—Audit & Lineage
Complete Invocation Trace — Version and Policy State at the Moment of Execution
Version and policy state captured per invocation
Self-contained trace — no post-hoc reconciliation
Tool-call granularity via OTEL collector in gateway
Export to Datadog, Grafana, Honeycomb, or any OTLP backend
Integrations
Works With Every Agent Source
Register agents and MCP servers from any provider into one governed catalog accessible through the Agent Gateway.
A2A Agents
Agent Source
MCP Servers
Server Source
AWS AgentCore
AWS Source
Azure AI Foundry
Azure Source
GitHub
Provider
Atlassian
Provider
CloudWatch
AWS Service
Slack
Provider
PagerDuty
Provider
Zendesk
Provider
+ any MCP-compatible server
Custom Source
Ready to Govern Your Enterprise AI Agents?
See how Jarvis Agent Registry brings order to your agent ecosystem with enterprise-grade governance, security scanning, multi-cloud federation, and a unified audit trail.
At a glance
Agent Registry
The Agent Registry is the catalog and lifecycle layer that makes enterprise AI agents governable: registered, scanned, versioned, scoped, and eventually retired. These 6 rows cover the lifecycle facts platform teams check first.
| Lifecycle stage | How the registry handles it |
|---|---|
| Registration | Agents are catalogued in place across 2 clouds — AWS AgentCore and Azure AI Foundry — keeping their existing pipelines. |
| Security scanning | Each registration is scanned before the entry becomes invocable, so an unreviewed agent is never reachable. |
| Versioning | Versions are first-class: a new revision publishes while existing workflows stay pinned to the version they bound to. |
| Deprecation | Deprecating a version blocks new bindings while active workflows drain, so retirement never breaks live traffic. |
| Access policy | RBAC and ACL together — the role grants capability, the ACL entry scopes which agents that role may invoke. |
| A2A traceability | Every hop records the calling identity, the target, the tools used, and the policy version then in force. |
Specifications
Agent Registry technical
A catalog is only trustworthy if its lifecycle rules are explicit. These rows state what is enforced at registration, what happens on deprecation, and which standards the identity and audit layers implement.
| Specification | Value |
|---|---|
| Catalog scope | 1 namespace covering A2A agents and MCP servers together |
| Federated sources | 3 — self-hosted, AWS AgentCore, Azure AI Foundry |
| Registration gate | 1 security scan per version, completed before the entry is invocable |
| Runtime scan cost | 0 ms added per invocation — the check runs at registration, not call time |
| Version binding | Consumers pin 1 version; a later revision cannot change it underneath them |
| Deprecation behaviour | New bindings blocked, active workflows drain, removal at 0 traffic |
| Access model | RBAC for capability plus per-resource ACL entries, evaluated on every call |
| Agent credentials | OAuth 2.0 (RFC 6749) client credentials per agent for A2A calls |
| Token format | JSON Web Token (RFC 7519) |
| Identity source | Azure EntraID via OpenID Connect Core 1.0 and SAML 2.0 |
| Transport security | TLS 1.2 minimum, TLS 1.3 preferred (RFC 8446) |
| Audit record | 4 fields per hop — calling identity, target agent, tools used, policy version |
| Telemetry format | OpenTelemetry OTLP |
| 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
Agents registered from AWS AgentCore
A 3-minute demonstration of AgentCore agents entering the catalog and becoming invocable from any interface, which is the registration path the lifecycle rules above govern.
Rollout
How to manage an agent through its lifecycle
The registry treats an agent the way a package repository treats a library: published, versioned, scoped, and eventually retired. These 5 steps describe one complete cycle.
Register and scan. Add the agent to the catalog; the registration scan runs before the entry is exposed to any caller.
Scope the policy. Attach the ACL entry defining which teams and which other agents are permitted to invoke it.
Publish a version. Consumers bind to a specific version, so a later revision cannot silently change behaviour underneath them.
Observe real usage. Use the audit trail to see which identities invoke the agent, through which chains, and under which policy version.
Deprecate, then retire. Mark the version deprecated to stop new bindings, let active workflows drain, then remove it once traffic is 0.
In practice
Catalog and audit views
Lifecycle management only helps if it is observable, so every catalog entry is paired with the audit history of how that agent has actually been used.
FAQ
Agent Registry questions we are asked most
Lifecycle questions decide whether an agent catalog stays trustworthy after the first quarter. These are the ones that come up before a platform team commits.
Deprecation blocks new bindings but leaves active workflows on the pinned version running, so retirement drains rather than breaks.
Once traffic to that version reaches 0, it can be removed. The audit trail shows exactly when that point is reached instead of leaving it to guesswork.
Both, and they do different jobs. RBAC establishes what a role is permitted to do in general; the ACL entry scopes that permission down to specific agents and tools.
The combination is what allows 2 teams with the same role to have genuinely different reach into the catalog.
Yes — agent-to-agent invocation is first-class. The calling agent carries its own OAuth client credentials and its permitted targets are declared in its ACL entry.
The full chain is visible in the audit trail, with each hop recording the invoking identity, the target, the tools called, and the policy version at that moment.
No. Agents stay in their home runtime with their existing deployment pipeline; the registry catalogs and governs them rather than hosting them.
That is deliberate — a catalog that required redeployment would only ever cover the agents someone had time to migrate.
Related resources
Jarvis resources
The registry sits between the gateways and the platform. These pages cover what it connects to on either side.
- Agent Registry FAQ the full question set on lifecycle, policy, and autonomous workflows.
- Agent Gateway the routing and enforcement layer in front of the catalog.
- Jarvis AgentFlow building the agent workflows that get published into the registry.
- Governed AI overview how identity, privacy, and observability combine across the platform.
- Jarvis AI platform FAQ licensing, hosting, and compliance questions across both products.
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. Agent identity, authorisation, and traceability follow the published frameworks below.
- Amazon Bedrock Agents documentation the AWS agent runtime federated into the catalog.
- RFC 6749 — OAuth 2.0 the credential model behind agent-to-agent invocation.
- NIST AI Risk Management Framework the governance reference behind registration scanning and audit.
- OpenTelemetry specification the trace format behind cross-agent observability.
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.