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.
Six core components catalog each enterprise agent's owner, capabilities, approval state, version, lifecycle, and policy so the gateway can enforce the current record.
Central registry for autonomous agents. Each agent is cataloged with identity, owner team, skills, and capability schema — auto-discovered via the A2A protocol.
Companion registry for MCP servers exposing tools, resources, and prompts. Merged with the agent registry into a single governed namespace accessible through one endpoint.
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.
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.
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.
Promote, deprecate, and retire agent versions with a single registry operation. Deprecation propagates to the gateway immediately — no workflow redeploys, no manual config changes.
Everything you need to catalog, govern, and operate AI agents and MCP servers at enterprise scale.
Register agents and MCP servers from any provider into one governed catalog accessible through the Agent Gateway.
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.
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. |
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 |
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.
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.
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.
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.
The registry sits between the gateways and the platform. These pages cover what it connects to on either side.
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.
