TL;DR. Mem0, until this week a memory vendor, launched Gateway on September 15, 2026: an access-control layer that sits between agents and their tools. The mechanism worth studying is the split it enforces between two acts that raw API keys collapse into one: connecting a tool, which stores a credential and grants nothing, and granting it, which gives one named agent one named capability under one revocable key. The launch also confirms a category-level convergence: LiteLLM shipped semantic MCP tool search with grant-aware ranking one day earlier, and the platforms that manage agent context are all converging on the same unclaimed job, deciding what an agent may do. That job is bigger than any one vendor's slice of it, and the interesting questions start where Gateway's own description stops.
Mem0 built its name on agent memory. On September 15 it shipped something that is not memory at all: Gateway, a proxy that holds your MCP server and API credentials, issues per-agent keys, and allows or refuses every tool call against a per-agent grant list. The announcement names three problems with how agents get access today, and they will be familiar to anyone who has wired an agent into production systems: the key does too much, internal APIs have no per-agent lock, and access is frozen at the moment of setup.
Product launches in this space arrive weekly. This one earns a closer read for two reasons: the mechanism is genuinely well designed, and the vendor shipping it tells you where the whole category is going.
Connect is not grant
The core of Gateway is a separation. An admin connects an MCP server through OAuth, or uploads an OpenAPI spec for an internal API; Gateway stores that credential once, encrypted, and uses it server-side. Connecting grants nothing. No agent can call anything until someone creates a grant: this agent, these named tools, nothing else. Mem0's worked example gives a research agent exactly two Linear tools, linear__list_issues and linear__get_issue; a call to linear__delete_comment is refused and the refusal is logged with its reason.
Every call therefore has to fit two nested boundaries. The connector's own permissions set the outer one, the ceiling: Gateway can never do more than the credential it holds. The per-agent grant draws the inner one, and it can be redrawn at runtime: widen it when the agent's job grows, tighten it when it shrinks, kill the agent and its next call is refused. None of that touches the upstream credential, which is the operational win. Anyone who has rotated a leaked key out of six agents' deployment configs understands what "no re-paste, no upstream rotation" is worth.
The agent itself never sees the upstream credential at all. Its mg_ key, issued with an expiry, a rate limit, and a spend cap, identifies the agent; the grant defines what the key can reach. This is the same inversion we examined when a catalog started minting scoped credentials for table access: stop handing out the powerful credential and start vending narrow capability under it. Gateway applies it to the whole tool surface, and adds the piece most credential-vending designs skip, an append-only record of every call, allowed or refused, attributed to the agent rather than to the shared service account.
Three meta-tools instead of a catalog
The second mechanism solves a different problem, context cost. An agent behind Gateway does not load tool definitions for everything it might call. It sees exactly three: discover, find_tools, and invoke. It searches for tools that fit the task, receives only the granted tools that match, and calls one by name. Mem0's framing: connect 500 tools and the agent still starts with three definitions in context, paying only for the handful it finds. The announcement is candid about the boundary of that saving, noting that harnesses like Claude Code already search tools client-side, so the gain concentrates on harnesses that load every definition upfront.
There is a quieter consequence. When tool selection moves server-side, the gateway's ranking function decides what an agent can see, and what an agent sees is what it does. We made the argument for MCP's instructions field that context injected by infrastructure goes unlogged; a search layer that returns some granted tools and not others is the same kind of surface, one step further from the prompt. Gateway at least keeps the grant boundary hard, finding a tool does not grant it, but the industry is now building ranking layers into the tool path, and the audit story for "why did the agent see these five tools" does not exist yet anywhere.
The escalation loop is the honest part
The feature that best matches how agents actually fail in production is the smallest one. When find_tools returns nothing that fits, the agent can search what the organization has connected but not granted, and call request_access with tool names and a reason. An admin reads the reason in the console and approves or denies; the request and its reason stay in the log.
This is the operational answer to access frozen at setup, and it is honest about the tradeoff: a short grant list is only practical if widening it is cheap. But cheap widening cuts both ways, and this is where our stale authorization argument applies with no modification. Grants accumulate. The research agent that requested comment access in March still holds it in September, three job-description changes later, and nothing in an approval-per-request model prompts the reverse question. Gateway gives you the primitives to tighten, the announcement even says "remove tools when the work no longer needs them," but the incentive gradient of every approval workflow ever shipped runs one way. Whether grant lists behind gateways stay short is going to be an empirical question about teams, not a property of the software.
One more consequence deserves naming. Gateway's per-agent record is now the authoritative account of who did what; the upstream system's own log still shows one service account for the whole connection. That concentration is the design working as intended, and it makes the gateway's log, and the gateway itself, the highest-value thing in the room: credential custodian for everything connected, sole holder of per-agent attribution. The same week Gateway launched, this category's stakes were on display elsewhere; capacity thieves are already building serving stacks inside stolen cloud accounts, and an access broker that holds every key is exactly the prize such intrusions look for. A gateway is a good trade, one hardened choke point instead of credentials scattered across agents, but it is a trade, not a free lunch.
A memory vendor selling the perimeter
Why is a memory company shipping this? Because the categories are collapsing into each other. The day before Gateway launched, LiteLLM, a gateway vendor from the model-routing side, released v1.101.0 with semantic MCP tool search that "ranks authorized tools," on top of a line that has been accreting MCP entitlements and grant-scoped listings since August. Catalog vendors rebranded as context layers and started absorbing governance. Now the memory vendor sells access control. Everyone who holds a piece of an agent's context is discovering that the adjacent job, deciding what the agent may do with that context, is unclaimed, load-bearing, and priced accordingly.
For the category's threat model and the full checklist a gateway needs to cover, our field guide to agent security gateways still applies; Gateway implements the authorization and audit slice of it cleanly and leaves content inspection and execution governance to others. What it settles is the direction: per-agent identity, capability grants, and attributed logs are becoming the default shape of agent access, arriving from three market directions at once in the same month.
Where Datapace fits
The unclaimed job looks the same where we sit, in front of the database. A Postgres role handed to an agent is the workspace-wide key with a different syntax: it does too much, it identifies no agent, and it is frozen at setup. Datapace is building the context layer between your databases and your AI: resolved schema meaning validated by the people who own the data, workload evidence beside it, and governed execution for what an agent may do and access, served over MCP. That is the same connect-is-not-grant posture applied to the place agents can do the most damage, with the context an agent needs in order to act correctly attached to the permission to act at all. No gateway, ours included, makes over-granting impossible; what it changes is whether the grant, the caller, and the consequence land in one attributable record. If your agents reach production data on credentials that name no agent, book a call.
Gateway is available now, and the pattern it ships is worth adopting even if the product is not the one you pick: two boundaries per call, identity per agent, an append-only account of everything refused. The refusals, it turns out, are the most informative log you can keep about an agent.
Sources
- Mem0, Give Every Agent Exactly The Tools It Needs, September 15, 2026 (launch announcement: connect/grant model, mg_ keys with expiry, rate limit and spend cap, worked Linear example, discover/find_tools/invoke, request_access flow, append-only records, retention-scoped bodies).
- Mem0, Gateway product page (tool-level access control positioning, per-tool allowlists, revocation without credential rotation).
- LiteLLM, release notes (v1.101.0, September 14, 2026: semantic MCP tool search ranking authorized tools, spend controls, grant-scoped listings; v1.96.0 MCP entitlements, August 9, 2026).