- MoEngage says it made about 400 private APIs usable by 10 internal AI agents, with no public endpoint and no MCP code written by product teams.
- MoEngage says its design hides tools an agent may not use and passes identity in headers the model never sees, so the model has nothing to change.
- Leaders should ask where their agents' permissions and identity are enforced. Server-side enforcement differs from a rule written into a prompt.
When a company lets an AI agent act inside its systems, the risky question is not how clever the model is. It is who decides what the agent can see, and who the agent claims to be. MoEngage's answer is that the model should decide neither.
Hundreds of private APIs, one access problem
MoEngage sells a customer engagement platform. AWS says more than 1,350 consumer brands use it to send push, email, SMS and WhatsApp messages. In an AWS blog post co-written with two MoEngage engineers, the company describes the problem its agents faced.
Across the company, 25 engineering teams have built what the post counts as roughly 400 internal REST APIs. They run in private networks across seven AWS Regions. MoEngage keeps them regional to meet data residency commitments and does not expose them to the public internet.
The agents needed those functions: campaign creation, segment queries, delivery stats. Nothing new had to be built. The work was making them reachable without opening a public door.
Why one server per team was rejected
The common route is for each team to run its own Model Context Protocol (MCP) server. MCP is a standard way for agents to discover and call tools. MoEngage counted more than 20 such servers to monitor, patch and keep compatible. Agents that span several domains would have to connect to many of them.
It set a rule instead. Product teams write REST APIs and declare which operations become tools. Only the AI Platform team operates the agent-facing layer. For this it used AgentCore Gateway, a managed service in Amazon Bedrock AgentCore that turns an API's OpenAPI description into MCP tools.
Three design choices that matter more than the product
The first choice is to cut the tool list before it is sent. MoEngage says each tool costs about 50 tokens of schema. That puts a full catalog above 20,000 tokens on every connection. Filtering on the client does not help, because the full list has already crossed the wire.
Instead, the gateway filters on the server. Each agent signs in with its own AWS identity, and a Cedar policy decides which tools that agent is shown. Cedar is an access-control language. The post says the gateway checks the agent's IAM role against the policy before it builds the tool list, so the list holds only permitted tools. A client-side filter works the other way round: it receives everything first and hides some afterwards.
Take the post's campaign QA bot. Its policy lets it see the tools that read campaigns and segments. Nothing that writes data ever appears in its list, because the gateway never sends those tools.
The second choice is to keep identity away from the model. Each call to an internal API must say which customer account, user, role and database it concerns. The calling service supplies that information as a small identity record. MoEngage's client library turns the record into HTTP headers. According to the post, the model does not see these headers and cannot set them.
This puts the trust in the calling service. The guarantee holds only if that service fills in the identity record correctly. The model simply has no field in which to change it.
The third choice is search over browsing. The model gets one tool, search_tools. It describes the task, the gateway returns matching candidates, and only those become callable for that turn. The full catalog stays out of the model's context.
A lesson about writing for machines
One finding is easy to miss. MoEngage says that reusing API descriptions as tool descriptions led to poor tool selection. Models chose tools by implementation detail such as "Returns a paginated list" rather than by intent.
So teams now write a separate, model-facing description. Exposure is also opt-in: an endpoint with no annotation is not a tool. The lesson here is that agents are a new kind of reader. Documentation written for developers does not serve them, and an API that was never meant for them should not become a tool by default.
What the evidence does and does not show
This is a vendor's account of a customer, published on AWS's own blog. The six months of saved engineering effort is MoEngage's estimate. So is the claim that onboarding now takes hours instead of days.
The scale is modest and specific. The post says the gateway serves roughly 400 operations to 10 internal agents and has run in production for three months. The post does not report how well the agents perform or whether any attack was attempted. It describes a sound structure, not a measured security result.
What leaders should ask their teams
Ask where each agent's permissions are enforced. If the answer is a line in a prompt, the model can be argued out of it. If it is a server-side policy, the model has no way to override it through conversation. That holds only if the policy itself is correct and not too broad, so ask who reviews it.
Ask who sets the agent's identity and tenant context, and whether the model can write them. If it can, move them out of its reach. If a calling service sets them, ask how that service is checked.
Ask what an agent receives on connection. A full tool list uses up context in tokens and shows the agent actions it should never be offered.
Ask who owns the agent layer. MoEngage kept it with one platform team so that product teams did not each learn a new protocol.
The idea worth keeping is simple. Treat an agent like a visitor with a badge: the building decides which doors it sees, and staff fill in the badge, not the visitor.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS.
