Your API gateway covers more agent traffic than the new vendors admit and less than you need — the boundary falls exactly where the unit of enforcement stops being the HTTP request.
The boundary in one table
The honest answer is neither "yes, buy a second box" nor "no, this is renaming." An API gateway enforces at the HTTP request. Roughly half of what agent traffic needs enforced does not live at the HTTP request — it lives inside a JSON-RPC body, across a delegation chain, across a multi-hour session, or in natural-language text that a WAF has no vocabulary for.
Twelve enforcement concerns, and where each one lands:
| Enforcement concern | Your API gateway | Verdict | Why |
|---|---|---|---|
| TLS, mTLS, transport hardening | Yes | Covered | Same wire, same problem |
| Authenticating the calling process | Yes | Covered | An agent runtime is an OAuth client like any other |
| Caller identity as a delegation chain (agent acting for a named user) | No | Structural gap | One consumer identity per connection; no second principal to carry |
| Per-tool authorization inside one JSON-RPC endpoint | Only with agent-aware plugins | Partial | Every tool is the same POST to the same path |
| Tool discovery as a policy decision | No | Structural gap | Route tables are static; tool catalogs are dynamic and model-consumed |
| Request-count rate limiting | Yes | Covered | Works, but limits the wrong unit |
| Budget and quota by token or dollar spend | Only with AI plugins | Partial | Requires parsing provider usage fields out of the response |
| Prompt-injection and tool-poisoning inspection | No | Structural gap | The attack is semantic; signatures and schemas do not see it |
| Audit at per-tool-call granularity with resolved arguments | Partial | Partial | Access logs record one POST, not which tool ran with which arguments |
| Egress control on agent-initiated outbound calls | Only if you force the path | Partial | Agents call out from the runtime, not through your ingress |
| Sessions and long-running transactions | No | Structural gap | Request/response proxies do not model a task that lives for hours |
| Human-in-the-loop interception mid-call | No | Structural gap | No mechanism to suspend a call and resume it on a human decision |
Four covered, four partial, four structural gaps. That distribution is the argument. If your agent estate only exercises the top of the table, you do not need a second box. If it exercises the bottom, no plugin configuration on a request-scoped proxy gets you there.
The steel-man, and the four assumptions agent traffic breaks
Concede what is true first, because the vendors selling a new box tend to skip it.
Every AI gateway sold by an API-gateway vendor is the API gateway. Kong's docs state that AI Gateway is "built on top of Kong Gateway" and that you enable AI features "through a set of modern and specialized plugins, using the same model you use for any other Kong Gateway plugin" [9]. Kong then ships an AI MCP Proxy plugin converting API schemas into MCP tool definitions, an AI MCP OAuth2 plugin, and MCP audit logs capturing session IDs, JSON-RPC method calls, payloads, latencies, and errors [10]. None of that required abandoning the API gateway. It required teaching it to read the body.
Same pattern in open source: agentgateway, contributed by Solo.io to the Linux Foundation in August 2025 with contributors including AWS, Cisco, IBM, Microsoft, and Red Hat, is one data plane for both traditional traffic and AI-native protocols. The announcement's own framing is that most existing gateways "were designed before the rise of AI agents and struggle to support modern AI protocols without major rearchitecture" [7].
Four properties of agent traffic sit behind every structural gap in the table.
The unit of authorization is not the request. DELETE /v1/invoices/8812 is a thing you can write policy about. MCP expresses everything as JSON-RPC over one endpoint: read_ticket and wire_funds are the same POST to the same path with different params. Path-and-method policy has nothing to grip.
The caller is a chain, not a client. Two principals are involved whenever an agent acts for a person. Microsoft's Entra documentation splits them explicitly. Under Autonomous access, "Agents can act autonomously, using access rights given directly to the agent identity." Under Delegated access, "Agents can act on behalf of human users, using access rights given to the user" [19]. A gateway consumer object holds one identity.
The payload is instructions, not data. A REST body is parsed. An agent payload is obeyed. OWASP's LLM01 defines indirect prompt injection as input an LLM accepts from external sources — websites or files — whose content, when interpreted by the model, "alters the behavior of the model in unintended or unexpected ways" [5]. Schema validation confirms the JSON is well-formed and says nothing about whether the string inside is an instruction.
The call pattern is non-deterministic and self-amplifying. A client makes the calls its code makes. An agent makes the calls its plan implies, and the plan changes with the input.
Caller identity and delegation: the row that decides it
If you evaluate one row, make it this one. Delegation is where "just add plugins" most reliably fails, because the missing thing is not a filter — it is a second principal the data model has no field for.
The requirement: a downstream system must authorize on both who the agent is and whose authority it exercises, at every hop. AWS built this into AgentCore Gateway as a token-exchange grant, where "the gateway exchanges the inbound user's access token for a new, scoped access token that targets a downstream resource," and "the exchanged token carries both the user's identity and the agent's identity, enabling downstream services to enforce fine-grained authorization at every hop without triggering additional consent flows" [16].
Note what that rules out. The naive approach — forward the inbound token downstream — is forbidden by the MCP specification: an MCP server calling an upstream API acts as an OAuth client to it and "MUST NOT pass through the token it received from the MCP client" [2]. AgentCore does expose a token-passthrough option that forwards the inbound token unmodified and leaves validation to the target, but AWS's own guidance calls passthrough "not the recommended approach for production" and points production workloads at the on-behalf-of exchange instead [17]. The audience rules exist because an unbound token can be replayed against a different resource, which is why MCP clients MUST send the RFC 8707 resource parameter in both authorization and token requests, and servers MUST validate that tokens were issued specifically for them [1].
An API gateway can validate a JWT and map claims to a consumer. What it lacks is a credential-exchange step minting a new, audience-scoped, dual-principal token per hop, and a per-agent identity lifecycle to hang it on. If an auditor must see which human authorized which action, this row is not optional — see what enterprise IdPs miss for agentic AI.
Inside the payload: per-tool authorization and tool discovery
Here the API gateway model genuinely extends — but only by giving up the thing that made it an API gateway. If the vocabulary here is new, the MCP gateway definition and the MCP pillar cover the primitives.
Kong's MCP tool ACLs define a default_acl applying to all tools, with per-tool acl objects that replace the default when present. Subjects are consumer names, consumer groups, or claim values; include_consumer_groups is a boolean the plugin reference defaults to false, and it must be enabled before group names can be used in an ACL at all [11]. A denied tool returns HTTP 403 rather than a JSON-RPC error [12]. Solo attributes the equivalent capability to its commercial tier — "Solo Enterprise for agentgateway selectively exposes tools based on defined policies, dynamically adjusting discovery and access so agents only see the tools they're authorized to use" — and its feature matrix marks "Enterprise OAuth scope restriction policies" as Enterprise-only, unavailable in the open-source build [8]. Google's Agent Gateway parses MCP request data specifically to enable attribute-based authorization rules [18].
All three read the JSON-RPC body, extract the tool name, and apply policy to a field rather than a path. So: yes, your API gateway can do per-tool authorization, if you run an MCP-aware plugin on it. The cost is two policy vocabularies — routes and services on one side, tool names and consumer groups on the other — with two change cadences.
Discovery is the harder half, and it has no HTTP analogue. A route table is authored by humans and read by the gateway. A tool catalog is authored by servers and read by a model, at runtime, every session. The response to tools/list is not metadata; it is the model's entire understanding of what actions exist, so filtering it is an enforcement action. Agent gateways treat it as one: AgentCore Gateway runs MCP targets in aggregation mode, combining backends into "a single unified virtual MCP server" where "clients see one consolidated tools/list response," plus a built-in semantic tool search [15].
The security case is concrete. Invariant Labs published tool-poisoning research on April 1, 2025 showing malicious instructions embedded in MCP tool descriptions are "invisible to users but visible to AI models," with a shadowing demonstration where one malicious server altered a trusted server's tool behavior [6]. A gateway that passes tools/list through untouched hands attacker-controlled prose straight into the model's context. That is the clearest single case where the two products are not doing the same job.
The published ceilings, where a vendor states them
Category arguments go better with numbers in front of them. AWS publishes AgentCore Gateway's service quotas, which is the closest thing available to a public statement of what an agent-protocol enforcement layer is dimensioned to hold. Defaults below, all of them listed as adjustable [21]:
| Quota | Default |
|---|---|
| Gateways per account | 1,000 |
| Targets per gateway | 100 |
| Tools per target | 1,000 |
| Tool name length | 256 characters |
| Gateway invocation timeout | 15 minutes |
| Maximum inline schema size | 1 MB |
| Maximum S3 payload schema size | 10 MB |
tools/call and tools/list rate | 200 TPS at gateway level, 200 TPS at account level |
tools/call and tools/list concurrent connections | 5,000 at gateway level, 5,000 at account level |
| Search-based tool-call rate | 25 transactions per minute |
| Maximum tool-call / tool-list / tool-search payload | 6 MB |
| Web Search tool request rate | 10 TPS |
Three readings.
The first rows say the aggregation problem is not hypothetical. A single gateway is dimensioned for 100 targets each publishing up to 1,000 tools. A tools/list off that surface is a catalogue no route table was ever asked to model, and filtering it is exactly the enforcement action the opening table marks as a structural gap.
The bolded row is the one to carry into a design review. Plain tool calls are rated at 200 per second; semantic tool search is rated at 25 per minute. The discovery mechanism that makes a large catalogue usable is metered far below the mechanism that consumes it — 25 a minute against 200 a second. If your architecture assumes the agent searches the catalogue on every turn, that assumption has a documented ceiling and it is low — cache resolved tool sets per task, or narrow the catalogue by policy before the agent ever searches it.
And the 15-minute invocation timeout is the quiet confirmation of the sessions row in the opening table: this layer is dimensioned for a call that is a task, not a call that is a request.
For the catalogue plane, the same source gives one number worth noting — AWS Agent Registry defaults to 5 registries per account per Region [21]. That is a governance artifact sized per organizational boundary, not a per-team convenience, which is consistent with how the registry section below frames it.
Non-determinism, cost, and the wrong rate-limit unit
Request-count rate limiting works on agent traffic. It just limits a quantity that no longer correlates with cost or risk. One turn against a 200k-context model and one against a small one both count as one request. A retry loop re-sending a growing conversation history is linear in requests and quadratic in spend. The gateway sees a flat line.
The AI-plugin answer is to count the right unit. Kong's AI Rate Limiting Advanced limits on prompt_tokens, completion_tokens, or total_tokens returned by the LLM provider, with a cost strategy that computes financial impact instead of raw tokens, and policy scoping by consumer, consumer group, IP address, header, path, model, and provider [13]. That is the correct shape of control, and it runs on an API gateway.
Here is the limit, documented by the vendor rather than inferred by me. Kong's guide to rate limiting agent-to-agent traffic states that "the AI A2A Proxy plugin does not extract token counts from A2A responses, so AI Rate Limiting Advanced has no token data to act on" [14]. The recommended control falls back to the standard Rate Limiting Advanced plugin at request-count granularity per consumer.
Read that as the general rule: token-aware limiting is real where the gateway can parse a known provider usage field and thin where it cannot — agent-to-LLM yes, agent-to-agent not yet, from a vendor shipping both. Put budget controls at the runtime as well as the edge.
Payload inspection: the attack is semantic, and WAFs are not
A web application firewall is a pattern matcher. The attack it must catch here is a sentence that means something.
OWASP's seven LLM01 mitigations are instructive because almost none is expressible as a rule: constrain model behavior, validate output formats, enforce privilege control, require human approval for high-risk operations, segregate untrusted content, run adversarial testing — and filter input and output against defined sensitive categories [5]. Only that last one is something a gateway can own.
That one is where the market went, and it went there by delegation. Google's Agent Gateway applies fine-grained access control by delegating to Model Armor for content sanitization alongside IAM and semantic governance policies, and frames itself as addressing "novel risks like Model Context Protocol (MCP) prompt injection attacks" [18]. Kong exposes the same class of control as a guardrails plugin family spanning AI Prompt Guard, AI Semantic Prompt Guard, AI PII Sanitizer, and integrations with Azure Content Safety, AWS Guardrails, GCP Model Armor, and Lakera Guard [9].
The procurement consequence: the classifier is usually not the gateway's own technology. It is a managed screening service the gateway calls. Your existing API gateway can plausibly call the same service — if it can extract the prompt from the body and act on a verdict. Whether that is a plugin install or a six-month project depends entirely on your gateway. Treat this row as partial and vendor-dependent, not a clean win for either box. The deeper stack is in prompt-injection defense for enterprise agents and MCP server security hardening.
Sessions, long-running tasks, and human-in-the-loop
The remaining gaps share a root cause: an API gateway's state model ends when the response is sent.
Agent protocols do not work that way. A2A operations are asynchronous by design — they return immediately with a Task or Message object while processing continues in the background, with clients tracking progress by polling, streaming (AgentCard.capabilities.streaming), or push notifications to a client-registered endpoint (AgentCard.capabilities.pushNotifications). The task lifecycle includes terminal states (TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, TASK_STATE_REJECTED) and interrupted states — TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED — that pause execution pending something outside the protocol [4].
An interrupted state is a policy moment. TASK_STATE_AUTH_REQUIRED means the task stopped because it needs authority it does not have. TASK_STATE_INPUT_REQUIRED means a human has to decide something. A request-scoped proxy has no representation for a transaction that is suspended and resumable, so it cannot enforce anything at that boundary.
MCP has the same shape on the tool side. Elicitation lets a server pause tool execution and request input through the client; form mode sends a JSON Schema the client renders, and responses use a three-action model — accept with content, decline, or cancel. Note which way the normative rule points: servers "MUST NOT use form mode elicitation to request sensitive information such as passwords, API keys, access tokens, or payment credentials" and "MUST use URL mode for interactions involving such sensitive information" — sensitive data is routed out of band, not forbidden outright. On the client side, "Clients SHOULD implement user approval controls" [3].
Practical consequence: if your control is "no irreversible action executes without a named human approving it," the enforcement point must be able to hold a call open. That is a session-aware component. Your API gateway is not one, and configuring it will not make it one.
Where the agent registry fits, briefly
A registry is not a smaller gateway. It is the catalog: what agents and tools exist, who owns them, which version is blessed, what policy is bound to each. The gateway is runtime enforcement of that record.
The category is real and dated. AWS Agent Registry entered preview on April 9, 2026 as "a private, governed catalog and discovery layer for agents, tools, skills, MCP servers, and custom resources within the organization," with semantic and keyword search, an administrator approval workflow, CloudTrail audit integration, and access via console, SDK, or as an MCP server queryable from an IDE, across five regions [20]. Kong lists an MCP Registry in Konnect as a tech preview [10].
For the question this page answers, the registry's relevance is narrow: it closes none of the rows in the opening table. It makes several of them maintainable — per-tool policy needs a canonical tool list, delegation needs a canonical agent identity, audit needs a version reference to attribute a call to. Buying a registry does not reduce your gateway requirement, and buying a gateway does not give you a catalog. The head-to-head, including the three failure modes when the two are procured separately, is at Agent Registry vs. Agent Gateway; the hubs are agent registry and agent gateway.
The rubric: when your existing stack is genuinely enough
Two thresholds decide this, and neither is about vendor quality.
Your API gateway plus an MCP-aware plugin layer is enough when all of these hold:
| Condition | Why it lets you stay |
|---|---|
| Agents run autonomously under their own service identity, not for named users | No delegation chain to carry; one consumer object is the truth |
| The tool catalog is small, first-party, and changes on your release cadence | Discovery filtering is a config file, not a runtime decision |
| Every tool is read-only or trivially reversible | Human-in-the-loop interception is not a control you need |
| Interactions are single-turn request/response | No session state for the gateway to fail to model |
| LLM spend is governed in the application, with the gateway as backstop | Request-count limits suffice at the edge |
You need a session-aware, protocol-aware layer when any of these hold:
| Condition | What breaks without it |
|---|---|
| Agents act for named humans against systems that audit who | Dual-principal tokens; the auditor cannot reconstruct authority |
| Third-party or community MCP servers are in scope | Tool descriptions are attacker-controlled input to your model |
| Any tool is irreversible — payments, deletes, outbound messages, infra changes | No place to hold a call open for approval |
| Tasks run for minutes or hours, or span agents | Interrupted task states are unenforceable at a request-scoped proxy |
| A regulator will ask which tool ran with which arguments under which policy | HTTP access logs record one POST |
The middle case is the common one and it has a cheap resolution: put an MCP-aware enforcement layer in front of the MCP surface only, and leave the rest of your API estate on the gateway you already run. AWS's own architecture endorses that shape — AgentCore Gateway's documented MCP target types include "API Gateway REST APIs" [15], so the agent-facing layer sits in front of the API gateway rather than replacing it. That is the deployment I would default to: not a rip-and-replace, not a second general-purpose proxy, but a narrow layer scoped to agent protocols, chained in front of the boring one.
One flag before you shop. Jarvis Registry sits in exactly this product category — it is our product, built by ASCENDING, which publishes this site, and I name it only because a page arguing this boundary should disclose that its publisher sells on one side of it. I have not benchmarked it against any vendor above, no capability claim here is drawn from it, and nothing on this page is a certification claim. Scoring products against criteria is a separate exercise — that is the job of how to shortlist an enterprise MCP gateway, and the evidence an auditor will ask for is enumerated in COSO's GenAI control-evidence guidance. For the protocol mechanics underneath all of it, start with MCP gateway auth and discovery.
FAQ
Is an agent gateway just an API gateway with new marketing?
Partly, and the partly matters. Every major AI gateway from an API-gateway vendor is built on that vendor's existing data plane — Kong states directly that AI Gateway sits on top of Kong Gateway and is enabled through plugins. Routing, consumer identity, and rate-limit primitives are genuinely reused. What is not reused is anything requiring the gateway to read a JSON-RPC body, carry two principals through a credential exchange, filter a dynamic tool catalog, or hold a transaction open across a human approval. Those are new capabilities, not new names. Judge each vendor claim against which of the four it actually implements.
Can I just put my MCP servers behind the API gateway I already run?
For transport security, caller authentication, and coarse rate limiting, yes — do it today, it is strictly better than exposing them directly. What you will not get by default is per-tool authorization, because every MCP tool is the same POST to the same path, and you will not get useful audit, because your access log records one request rather than which tool ran with which arguments. Kong and others solve both with MCP-aware plugins on the same gateway. If your gateway has no such plugin, the gap is real and configuration will not close it.
What is the single strongest reason to add a dedicated layer?
Delegation. When an agent acts on behalf of a named human, downstream systems must authorize against both identities at every hop, which requires exchanging the inbound token for a new audience-scoped token carrying both principals. AWS documents exactly this as a token-exchange grant in AgentCore Gateway. The MCP specification separately forbids the shortcut: a server must not pass the client's token through to an upstream API. An API gateway's consumer model holds one identity, so this is not a policy you can express there regardless of which plugins you install, and it is the row most likely to force a decision.
Does an agent registry replace either gateway?
No. A registry is the catalog plane — which agents and tools exist, who owns them, which version is approved, what policy is bound. It performs no runtime enforcement. AWS Agent Registry entered preview in April 2026 as a governed catalog with approval workflows and CloudTrail audit: governance metadata, not a call path. The registry makes gateway policy maintainable by giving it a canonical tool list, agent identity, and version reference to enforce against. Buying one does not reduce the other requirement. The head-to-head is covered separately on this site.
Where does prompt-injection screening actually belong?
Not exclusively at the gateway, and rarely as the gateway's own technology. The screening classifiers in this market are managed services the gateway delegates to — Google's Agent Gateway names Model Armor as its content-sanitization delegate, and Kong exposes third-party guardrail engines as plugins. OWASP's LLM01 mitigations are mostly architectural: constrain tool capability, segregate untrusted content, require human approval for high-risk actions. Screening at the edge is one layer of several, and it is the only one of the seven that a gateway can own outright. If it is your only layer, the control is thinner than the product page suggests.
References
- MCP servers act as OAuth 2.1 resource servers; clients MUST send the RFC 8707
resourceparameter in authorization and token requests, and servers MUST validate the token audience — Model Context Protocol (2026): https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization - An MCP server acting as an OAuth client upstream MUST NOT pass through the token it received from the MCP client — Model Context Protocol (2026): https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
- Elicitation pauses tool execution for user input, forbids form mode for sensitive information, mandates URL mode for it, and defines an accept/decline/cancel response model plus client user-approval controls — Model Context Protocol (2026): https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation
- A2A operations are asynchronous, with interrupted task states (
TASK_STATE_INPUT_REQUIRED,TASK_STATE_AUTH_REQUIRED) and streaming or push-notification progress declared on the Agent Card — Agent2Agent Protocol (2026): https://a2a-protocol.org/latest/specification/ - LLM01:2025 defines indirect prompt injection and lists seven mitigations, of which only category-based filtering is gateway-owned — OWASP GenAI Security Project (2025): https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- Tool Poisoning Attacks embed instructions in MCP tool descriptions that models read and users never see; the shadowing demo showed one malicious server altering a trusted server's tools — Invariant Labs (2025): https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
- agentgateway was contributed by Solo.io to the Linux Foundation on August 25, 2025, with the stated problem that most existing gateways predate AI agents and struggle with modern AI protocols without major rearchitecture — Linux Foundation (2025): https://www.linuxfoundation.org/press/linux-foundation-welcomes-agentgateway-project-to-accelerate-ai-agent-adoption-while-maintaining-security-observability-and-governance
- Solo Enterprise for agentgateway selectively exposes tools by policy and adjusts discovery and access dynamically; the Enterprise-versus-open-source matrix marks OAuth scope restriction policies and advanced access controls as Enterprise-only — Solo.io (2026): https://docs.solo.io/agentgateway/latest/about/overview/
- Kong AI Gateway is built on top of Kong Gateway and enabled through plugins; guardrails span AI Prompt Guard, AI Semantic Prompt Guard, AI PII Sanitizer and third-party engines — Kong (2026): https://developer.konghq.com/ai-gateway/
- Kong's MCP Traffic Gateway documents the AI MCP Proxy and AI MCP OAuth2 plugins, tool aggregation, MCP audit logs capturing session IDs and JSON-RPC method calls, and an MCP Registry in Konnect as tech preview — Kong (2026): https://developer.konghq.com/mcp/
- Kong's AI MCP Proxy configuration reference defines
default_acland per-toolaclallow/deny lists over consumer names, consumer groups or claim values, and documentsinclude_consumer_groupsas a boolean defaulting tofalse— Kong (2026): https://developer.konghq.com/plugins/ai-mcp-proxy/reference/ - Kong's MCP tool access-control how-to shows consumer and consumer-group ACLs in practice and returns HTTP 403 Forbidden on denial — Kong (2026): https://developer.konghq.com/mcp/use-access-controls-for-mcp-tools/
- Kong's AI Rate Limiting Advanced plugin limits on
prompt_tokens,completion_tokensortotal_tokens, offers acoststrategy, and scopes policies by consumer, group, IP, header, path, model and provider — Kong (2026): https://developer.konghq.com/plugins/ai-rate-limiting-advanced/ - Kong's A2A rate-limiting guide states AI Rate Limiting Advanced cannot be applied to A2A because the AI A2A Proxy plugin does not extract token counts from A2A responses — Kong (2026): https://developer.konghq.com/how-to/rate-limit-a2a-traffic/
- AgentCore Gateway aggregates MCP targets into a single unified virtual MCP server with one consolidated
tools/listresponse and semantic tool search, and lists API Gateway REST APIs among its MCP target types — Amazon Web Services (2026): https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-core-concepts.html - AgentCore Gateway's token-exchange (on-behalf-of) grant mints a scoped downstream token carrying both the user's and the agent's identity — Amazon Web Services (2026): https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html
- AgentCore's inbound-authorization guidance states that token passthrough is not the recommended approach for production and directs production workloads to on-behalf-of token exchange — Amazon Web Services (2026): https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-inbound-auth.html
- Google Cloud's Agent Gateway governs ingress and egress, authenticates with mTLS and DPoP, parses MCP request data for attribute-based authorization, and delegates content sanitization to Model Armor — Google Cloud (2026): https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview
- Microsoft Entra agent identities support autonomous access using access rights given directly to the agent identity, and delegated access where agents act on behalf of human users — Microsoft (2026): https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities
- AWS Agent Registry entered preview on April 9, 2026 as a private, governed catalog and discovery layer for agents, tools, skills and MCP servers, with approval workflows and CloudTrail audit across five regions — Amazon Web Services (2026): https://aws.amazon.com/about-aws/whats-new/2026/04/aws-agent-registry-in-agentcore-preview
- Source of the AgentCore Gateway quotas tabulated above — 1,000 gateways per account, 100 targets per gateway, 1,000 tools per target, 256-character tool names, a 15-minute invocation timeout, 1 MB inline and 10 MB S3 schema sizes, 200 TPS and 5,000 concurrent connections for
tools/callandtools/listat both gateway and account level, a 25-per-minute search-based tool-call rate, a 6 MB tool payload ceiling and 10 TPS for the Web Search tool — plus the 5-registries-per-account-per-Region default for AWS Agent Registry. Vendor-published quotas — Amazon Web Services (2026): https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html