Everything you need to know
about the Agent Registry

No. The federation layer imports agents from AWS AgentCore and Azure AI Foundry into the registry catalog without redeployment. Federated agents continue running in their original environment — the registry stores a reference and a capability snapshot, and the gateway routes to them through the federation endpoint.

Once federated, these agents inherit the same RBAC, ACL policies, versioning, and audit trail as natively registered agents. From the perspective of any workflow or copilot connecting through the gateway, a federated AWS agent and a natively registered agent are indistinguishable.

The current federation layer supports AWS AgentCore and Azure AI Foundry out of the box. Both use the federation tab in the Jarvis Registry UI to configure the connection — AWS via IAM role assumption, Azure via service principal with Azure AD SSO.

The federation architecture is protocol-based rather than provider-specific, so additional providers can be added through the external providers API. Contact us if you have a specific provider requirement.

The registry maintains a synced capability snapshot for each federated agent. Changes to the agent in its source environment — updated tool definitions, changed endpoint, new version — are detected on the next sync cycle and reflected in the registry catalog. The sync interval is configurable; the default is 15 minutes, and you can trigger a manual sync at any time from the federation tab.

Any capability change that triggers a re-scan will hold the agent in a pending-review state until the scan passes, even for federated agents. This prevents a silently updated external agent from bypassing your security gate.

The registration pipeline runs three checks before an agent becomes active in the catalog.

Capability declaration scan: validates the agent schema against allowed capability patterns. Detects over-broad tool claims, missing required fields, and schema constructs that could be used to mislead an orchestrator about what the agent actually does.

Prompt injection scan: detects injection payloads embedded in the agent's name, description, or capability fields. A malicious actor registering an agent with injected instructions in its description is a real attack vector; this check blocks it at the publish gate.

Policy compliance check: verifies the agent declared behavior does not conflict with active enterprise policy rules. Agents fail this check if they claim capabilities that are restricted or require explicit approval for your organization.

Agents remain in inactive state until all three pass. Any update to the agent card re-triggers the full pipeline.

Policy propagation from registry to gateway enforcement is real-time — not a sync interval or cache TTL. When you revoke a user access or deprecate an agent version, the gateway reflects the change immediately on the next invocation attempt.

This is a security requirement, not a performance optimization. The window between a policy change and its enforcement is a security exposure — an attacker who has been granted access that is subsequently revoked must find that access blocked immediately, not after a cache expires.

No. The registry enforces a publish gate — agents in pending or scan-failed state are not visible to the gateway routing layer and cannot be invoked. The gateway returns a 404 Not Found for any invocation targeting an agent that has not passed its scan and been explicitly published.

This applies to both newly registered agents and agents whose card was updated — a capability change puts the agent back into pending until the re-scan completes, preventing a silent update from bypassing the security gate.

The registry supports both, applied in layers. RBAC scopes define broad permissions by role — for example, sre-engineer can invoke all agents in the ops namespace. ACL entries layer on top for per-agent, per-identity fine-grained control — for example, blocking a specific team from a specific agent even if their role would otherwise permit it.

Access policy objects are defined in the registry and propagated to the gateway in real time. The gateway evaluates both layers on every invocation: role first, then per-resource ACL overrides. Deny always wins over allow when there is a conflict.

The Identity & Access Layer supports any OIDC-compliant identity provider. Tested integrations include Azure EntraID, Okta, Auth0, and AWS IAM Identity Center. JWT tokens from your IdP are validated at the gateway; claims are mapped to registry RBAC roles and ACL identities via a configurable claim-mapping policy.

Machine-to-machine invocations — orchestrators, CI pipelines, and other agents invoking agents — use OAuth 2.0 client credentials flow with audience-separated JWTs so each agent token cannot be replayed against a different agent.

Access revocation flows from your IdP — when an account is deprovisioned in Azure EntraID or Okta, their OIDC tokens stop being issued and existing tokens expire naturally. For immediate revocation before token expiry, the registry provides a per-identity block list that the gateway checks on every request, bypassing token validity entirely.

The revoked identity is also marked in the registry ACL audit log so there is a permanent record showing when access was removed and which agent resources were affected. This supports offboarding compliance requirements without any manual policy cleanup in individual agent configs.

Deprecating a version in the registry immediately stops the gateway from routing new invocations to it. Active workflows automatically route to the current approved version — no workflow redeploys, no orchestrator config changes needed.

This is the blast radius control pattern: one registry operation immediately propagates to all active workflows. If a version needs to be deprecated urgently due to a defect or security issue, the single registry action is sufficient to stop exposure across every consumer.

Yes. The registry maintains the full version history for each registered agent. Promoting a previous version back to current status re-activates it immediately — the gateway reflects the change without any config update on the workflow or orchestrator side.

The rollback action itself is recorded in the audit trail with the operator identity, timestamp, and the previous state — supporting post-incident review and compliance documentation.

The registry supports version-pinning at the access policy level. A workflow or team can be bound to a specific agent version via their ACL entry — they continue receiving that version even after a new one becomes the org-wide current. This allows gradual rollouts: new version active for most consumers, while a team that has not migrated yet stays pinned to the previous one.

Version pins are tracked in the registry and visible in the audit trail. The registry surfaces a warning when a pinned team is running a deprecated version, prompting migration without forcing a breaking change.

Autonomous workflows — where the LLM selects agents at runtime — need a bounded agent pool, not an open catalog. The registry defines which agents an LLM may consider for a given workflow, and the gateway enforces that boundary at invocation time. The LLM cannot reach outside the approved set, regardless of what it decides to invoke.

Without this constraint, autonomous means unconstrained. A misconfigured or adversarially prompted LLM could invoke any reachable agent. The registry provides the explicit allowlist that makes autonomous safe enough to deploy in production.

Yes, at two layers. First, the registration security scan detects injection payloads in agent capability declarations — a malicious agent trying to hijack an LLM behavior by embedding instructions in its description is blocked at publish time. Second, because the registry defines the bounded agent pool available to any given workflow, a prompt injection attack that attempts to redirect an LLM to invoke an unregistered or out-of-scope agent fails at the gateway — the agent simply is not in the allowed set.

The registry does not replace runtime content filtering, which belongs in the gateway traffic layer, but it eliminates the catalog-level attack surface.

Agent-to-agent invocations are first-class in the registry. Each agent that can invoke other agents carries its own OAuth client credentials, and its allowed target agents are defined in its ACL entry — an orchestrator agent may invoke the diagnosis agent and the remediation agent, but not the billing agent, even if all four are in the same catalog namespace.

The A2A invocation chain is fully visible in the audit trail: each hop records the invoking agent identity, the target agent, the tools called, and the policy version in effect at that moment. This gives you end-to-end traceability for multi-agent workflows without any instrumentation on the agent code itself.