An agent gateway is an access and routing layer between AI clients and the agents or tools they use. It can check the caller, apply access rules and forward requests. It covers only the connections that pass through it. A local tool or direct backend connection outside that route needs its own controls.
For a company choosing a gateway, the useful question is specific: can the permitted employee complete the required task while another employee is blocked? Then check the records for both attempts. Jarvis Registry, built and maintained by ASCENDING, combines a resource catalog with MCP and A2A gateway capabilities. This guide separates those documented capabilities from the tests your deployment still needs.
What should an agent gateway control?
Start with identity, resource access, routing and evidence. A product label does not establish per-tool permissions, complete audit records or a particular revocation time. Write the requirement as an observable result before comparing vendors.
For protected HTTP-based MCP connections, the MCP authorization specification defines discovery and token-handling requirements. Tokens need the correct intended audience. The security guidance also rejects using an incoming token as an unchecked credential for another service. The gateway and the service it calls enforce separate permissions.
| Control | Result to demonstrate | Boundary to keep visible |
|---|---|---|
| Caller identity | A valid user connects; an invalid or expired credential is rejected. | Signing in is different from authorization to a particular resource. |
| Resource access | A permitted user discovers and calls the registered server; a denied user cannot call it by ID. | A hidden catalog item alone does not prove runtime denial. |
| Tool selection | The requested operation is allowed or denied through the selected client connection. | A server-wide disabled tool is not a per-user tool permission. |
| Business data | The downstream system applies the required operation and record permissions. | Shared service credentials may have a different scope from the employee. |
| Evidence | Reviewers can join the request, decision and observed result. | Metrics or an LLM trace alone may not contain the full authorization record. |
Use the Entra ID access-control guide for a two-user test design. It separates sign-in, gateway-resource access and downstream-system permission.
Agent gateway, MCP registry and skill registry: which do you need?
A registry describes and organizes resources. A gateway controls an execution path. A private skill registry manages reusable instruction packages, such as SKILL.md files, and their distribution. An MCP server supplies tools that a client can call. These objects can live in one product while retaining different permission and lifecycle boundaries.
Use a gateway when your requirement concerns a request reaching a tool or agent. Use skill management when the requirement concerns who can obtain or update an instruction package. You may need both. Removing a downloaded skill from a catalog does not automatically revoke credentials to the business system it can instruct an agent to use.
| Buyer need | Relevant layer | Useful follow-up |
|---|---|---|
| Find approved agents and tools | Agent or MCP registry | Check ownership and how discovery is scoped. |
| Control calls to a registered resource | Gateway and resource authorization | Test a known-ID call, not only catalog search. |
| Share private coding instructions | Skill registry and client distribution | Check package ACLs, revision handling and local copies. |
| Limit actions on company records | Downstream authorization | Test the actual read or write with the intended credential. |
The agent-registry versus skill-registry guide explains the catalog distinction. For private package hosting and delivery, see the self-hosted skill-registry guide.
How is an agent gateway different from an API gateway?
An API gateway can already provide authentication, routing, rate limits and request logs. An agent gateway adds capabilities for the agent protocols and resource types it supports. Do not assume an API gateway loses identity after one hop, or that any agent gateway preserves identity through every downstream service.
Compare the exact request path. For MCP, check tool discovery, the advertised transport, authorization and execution. For A2A, check agent discovery and invocation. For downstream APIs, check the credential and the service policy. The same deployment may use all three paths.
A team with an existing gateway should first identify the missing control. If the current stack already meets the requirement, another gateway adds an operating component without necessarily closing a gap. The agent gateway versus API gateway comparison helps separate protocol behavior from features a vendor has actually implemented.
| Question | API gateway evaluation | Agent gateway evaluation |
|---|---|---|
| Which traffic is covered? | Identify the routed HTTP endpoints and policies. | Identify the supported MCP or A2A paths, plus bypass routes. |
| Whose identity reaches the backend? | Inspect the configured credential or identity exchange. | Inspect both client identity and downstream credential handling. |
| What operation can be denied? | Test the endpoint, method or application policy. | Test the resource, tool and downstream operation separately. |
| What can an investigator reconstruct? | Inspect access logs and application records. | Inspect protocol-aware records where provided, then join downstream evidence. |
A small gateway evaluation your platform team can run
Use a non-production server with harmless synthetic data and two identities. The checks below are acceptance criteria, not a claim that a particular tenant has passed. Record the deployed version and client connection mode with every result.
- 01
Check both discovery and execution
Give one user access to the test resource. Keep the other denied. Test search and a direct call using the known resource ID.
- 02
Separate server and tool rules
If both users can reach one server, test whether individual operations can differ by user. Document where that rule is enforced.
- 03
Measure permission changes
Change one grant and repeat through the same client, an existing session and a fresh session. Record when the denial appears; do not assume instant propagation.
- 04
Verify the business-system boundary
Repeat an approved read and a denied write in the downstream application. Confirm the credential and record scope actually used.
- 05
Reconstruct one allowed and one denied request
Collect sanitized identity, resource, operation, time, decision and result. Identify missing fields before calling the record complete.
- 06
Name the operator
Assign upgrades, backups, monitoring, incident response and configuration changes. A customer-cloud deployment does not by itself name the operating team.
The public Jarvis MCP access walkthrough supplies a bounded test sequence. Its local sample checks the synthetic server; your Registry connection and permission checks still need deployment testing. For evidence design, use the MCP tool-call audit guide.
Where Jarvis Registry fits
Jarvis Registry documentation describes a catalog and gateway for registered MCP servers, A2A agents and private skills. It documents OAuth/OIDC identity integration, role capabilities and resource ACLs. Its federation guides cover AWS AgentCore Runtime and Azure AI Foundry agents. Confirm the transport, authentication and registration prerequisites for your target runtime.
The tool-enablement contract is more specific than a general fine-grained-access claim. Disabled tools are configured per server, not per user. Normal discovery filters them and execute_tool rejects them. The transparent proxy does not enforce that disabled-tools list. Different read and write rights for each user need a separate access design.
The observability guide describes platform monitoring and agent LLM trace collection. Check your deployment for the identity, operation, policy and downstream-result fields the audit requires. Monitoring alone does not prove that every call has a saved policy snapshot.
For private skills, the Skill Gateway is the authoring and governance surface. It imports from supported Git providers, including GitHub and GitLab. Its client-delivery workflow supports Claude Code, Codex, GitHub Copilot and Cursor. Package access and a client’s locally stored copy are separate checks.