AgentCore Gateway: How MoEngage Turned 400 Private APIs Into Permission-Scoped Agent Tools

MoEngage runs roughly 400 private REST APIs across 7 AWS Regions. They needed agents to call these APIs without writing 400 MCP servers, exposing public endpoints, or cramming 400 tool definitions into every agent's context window.

Amazon Bedrock AgentCore Gateway solves this by sitting between the agent orchestrator and internal APIs. It reads OpenAPI specs, generates tool schemas, filters tools by Cedar permission policies, and routes calls through Amazon VPC Lattice to private backends. The agent sees only the tools it has permission to use.

This is infrastructure for tool boundaries at scale.

The 400-API Problem

Most agent tool tutorials show you how to wrap one or two APIs in an MCP server. That works until you have hundreds of internal services.

What breaks at scale:

• Context window bloat: Sending 400 tool definitions to the agent on every turn wastes tokens and slows planning.
• Permission sprawl: Different users need different subsets of tools. Hard-coding this in the orchestrator is unmaintainable.
• Network exposure: You don't want to make internal APIs publicly accessible just so an agent can call them.
• MCP server proliferation: Writing and deploying a separate MCP server for each backend service creates operational overhead.

MoEngage's setup spans multiple AWS Regions. Their APIs handle customer engagement workflows, analytics queries, and campaign management. Agents need to orchestrate across these services based on user permissions and regional boundaries.

How AgentCore Gateway Works

AgentCore Gateway is a managed service that acts as a dynamic tool registry and execution proxy.

Architecture flow:

1. Tool registration: You upload OpenAPI 3.x specs for each backend API. The gateway parses these into tool schemas (name, description, parameters, response shape).
2. Permission filtering: Cedar policies define which users or roles can access which tools. When an agent session starts, the gateway evaluates policies and returns only the permitted tool subset.
3. Agent planning: The orchestrator (Amazon Bedrock Agents or custom) receives the filtered tool list and includes it in the agent's context.
4. Tool execution: When the agent decides to call a tool, the gateway validates the request against Cedar policies again, then routes the call through Amazon VPC Lattice to the private API.
5. Response handling: The gateway returns the API response to the agent. Errors surface as tool execution failures.

Key components:

OpenAPI to Tool Schema Translation

The gateway reads your OpenAPI spec and generates a tool definition the agent can understand.

Example OpenAPI snippet:

paths: /campaigns/{campaignId}/send: post: operationId: sendCampaign summary: Send a marketing campaign to a segment parameters: - name: campaignId in: path required: true schema: type: string requestBody: required: true content: application/json: schema: type: object properties: segmentId: type: string scheduleTime: type: string format: date-time responses: '200': description: Campaign queued content: application/json: schema: type: object properties: jobId: type: string 

Generated tool schema (simplified):

{ "name": "sendCampaign", "description": "Send a marketing campaign to a segment", "parameters": { "type": "object", "properties": { "campaignId": { "type": "string" }, "segmentId": { "type": "string" }, "scheduleTime": { "type": "string", "format": "date-time" } }, "required": ["campaignId", "segmentId"] } } 

The gateway handles parameter merging (path, query, body), type coercion, and response unwrapping. If the API returns paginated results, you can annotate the OpenAPI spec with extension fields to tell the gateway how to iterate.

Cedar Policies for Permission Scoping

Cedar is a policy language designed for fine-grained authorization. AgentCore Gateway evaluates Cedar policies at two points: when building the tool list and when executing a tool call.

Example Cedar policy:

permit( principal in Role::"CampaignManager", action == Action::"sendCampaign", resource in Region::"us-east-1" ); 

This policy allows users in the CampaignManager role to call the sendCampaign tool, but only for resources in us-east-1.

What happens at runtime:

• Session start: The gateway evaluates all policies for the authenticated user and returns only the tools they can access. If a user has no permission for sendCampaign, that tool never appears in the agent's context.
• Tool execution: Even if the agent somehow tries to call a forbidden tool (malicious prompt injection, for example), the gateway re-evaluates the policy and rejects the call before it reaches the backend API.

This double-check prevents context poisoning attacks where an attacker tricks the agent into calling a tool it shouldn't have access to.

VPC Lattice for Private API Routing

Amazon VPC Lattice is a managed service mesh that routes traffic between VPCs and on-premises networks without exposing public endpoints.

How it works with AgentCore Gateway:

1. Your backend APIs run in private subnets across multiple VPCs and Regions.
2. You create a VPC Lattice service for each API and register it with the gateway.
3. When the agent calls a tool, the gateway looks up the corresponding Lattice service and forwards the request.
4. Lattice handles TLS termination, load balancing, and cross-Region routing.

Security boundaries:

• No public IP addresses on backend APIs.
• No VPN tunnels or peering connections to manage.
• Traffic stays within the AWS backbone.
• You can attach IAM policies to Lattice services for additional access control.

MoEngage's 7-Region setup means a single agent session might call tools in us-east-1, eu-west-1, and ap-south-1. Lattice routes each call to the correct Region without the agent needing to know the topology.

Failure Modes and Observability

Common failure scenarios:

Observability hooks:

• CloudWatch Logs: Gateway logs every tool call with user principal, tool name, parameters, response status, and latency.
• CloudWatch Metrics: Tool call count, error rate, latency percentiles, and permission denial rate.
• X-Ray tracing: End-to-end trace from agent orchestrator through gateway to backend API.

You can set up alarms for high error rates or permission denials. If a specific tool starts failing frequently, you can investigate the backend API or update the OpenAPI spec.

Rate Limiting and Circuit Breaking

The gateway does not include built-in rate limiting or circuit breaking. You need to handle this at the backend API layer or with an intermediate proxy.

Options:

• API Gateway: If your backend APIs are already behind API Gateway, use its throttling and quota features.
• Application Load Balancer: Configure connection limits and health checks.
• Service mesh: Use AWS App Mesh or a third-party mesh to implement circuit breakers.

The gateway will propagate rate limit responses (HTTP 429) back to the agent. Your orchestrator should implement retry logic with exponential backoff.

When Permission Errors Surface

If an agent tries to call a tool it doesn't have permission for, the error surfaces at execution time, not planning time.

Why this matters:

• The agent's context includes only permitted tools, so under normal operation it won't try to call forbidden tools.
• If a prompt injection attack tricks the agent into attempting a forbidden call, the gateway blocks it and returns an error.
• The agent can handle this error like any other tool failure (retry, ask for clarification, or abort the task).

This design prevents the agent from learning about tools it can't use, which reduces the attack surface for social engineering.

Deployment Shape

MoEngage's setup looks like this:

• AgentCore Gateway: Single managed service per AWS account, configured with OpenAPI specs and Cedar policies.
• Backend APIs: ~400 private REST services across 7 Regions, each registered as a VPC Lattice service.
• Agent orchestrator: Amazon Bedrock Agents or custom orchestrator, calls gateway to fetch tool list and execute tools.
• IAM roles: Each user or application has an IAM role that maps to Cedar principals.

Operational overhead:

• OpenAPI maintenance: When a backend API changes, update its OpenAPI spec and re-upload to the gateway.
• Policy updates: When permission rules change, update Cedar policies.
• Monitoring: Watch CloudWatch metrics for tool call errors and latency spikes.

No per-service MCP servers to deploy or version. No public endpoints to secure. The gateway handles schema validation, permission checks, and routing.

Technical Verdict

Use AgentCore Gateway when:

• You have dozens or hundreds of internal APIs that agents need to call.
• Different users need different subsets of tools based on roles or permissions.
• Your APIs are private and you don't want to expose them publicly.
• You want centralized observability for all agent tool calls.
• You already use AWS and can integrate with VPC Lattice and Cedar.

Avoid it when:

• You have fewer than 10 tools and can manage them with simple MCP servers.
• Your APIs are already public and don't need permission scoping.
• You need sub-millisecond tool call latency (the gateway adds network hops).
• You want full control over the tool execution layer and don't want a managed service.
• You're not on AWS or need multi-cloud tool routing.

The gateway solves a real problem: how to give agents access to enterprise-scale internal APIs without manual tool proliferation or security compromises. If you're building agents that orchestrate across many backend services, this is the infrastructure layer you need.

Source Links

• How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway