How Customer Agents on Your API works
Data flow
- 1A customer's AI agent calls your API or MCP server on behalf of one of their users.
- 2Your OAuth server issues scoped, short-lived tokens after the user consents. Agents never get long-lived API keys.
- 3An allowlist of client ID metadata documents (CIMD) decides which agent apps may ask for tokens. Open dynamic registration stays off.
- 4The gateway checks every token and rate-limits per client. The MCP server, not the gateway, validates tool arguments.
- 5Your MCP server exposes a small set of scoped tools, read-only first, and reaches your services only within the user's tenant and scopes.
- 6Writes and destructive actions need the user's confirmation outside the agent, tied to that exact action.
- 7Every call is logged per client and per tenant, so you can spot and revoke a misbehaving agent.
Build or buy
Buy + glueWhat you can buy for each box in the diagram, the open source option, and the part you still build yourself.
| Component | Buy | Open source | You build | Maturity |
|---|---|---|---|---|
| Customer's agent | Claude, ChatGPT, Cursor, VS Code and custom clients | · | Test the OAuth flow with every client you list as supported | GA |
| API / MCP gateway | Cloudflare (Advanced Rate Limiting on Enterprise for per-client limits), Kong AI Gateway Enterprise, Zuplo MCP Gateway | agentgateway, Kong Gateway OSS, Envoy | Rate limits keyed by OAuth client and tenant | GA |
| Your OAuth server | Auth0 Auth for MCP, WorkOS AuthKit, Descope, Stytch Connected Apps | Keycloak, Ory Hydra, Cloudflare workers-oauth-provider | Scope design, consent text, short token lifetimes, per-client revocation | GA |
| Client allowlist | CIMD allowlists and pre-registered clients in Auth0, WorkOS, Descope or Stytch | Keycloak | Admin setting that lets each customer choose which agent apps their tenant allows | GA |
| Your MCP server | Hosting only, such as Cloudflare Workers or your own infrastructure | Official MCP SDKs | Small read-first toolset, argument validation, output trimming, tenant isolation | GA |
| Confirm step | Auth0 asynchronous authorization (CIBA), MCP URL-mode elicitation | · | Out-of-band approval page, single-use confirmation tied to the exact action and arguments | Preview |
| Your services and data | · | · | Take the tenant from token claims, never from tool arguments, and enforce row-level checks | GA |
| Agent activity log | WorkOS Audit Logs or your existing log stack | OpenTelemetry | Log view each customer can see, plus a revoke button per agent app | GA |
Rollout steps
| # | Step | Who | Effort |
|---|---|---|---|
| 1 | Choose three to eight read-only tools and define scopes for them | Product manager and backend engineer | 1 week |
| 2 | Set up the auth vendor with protected resource metadata, CIMD, pre-registered clients and short-lived tokens | Backend or identity engineer | 1-2 weeks |
| 3 | Build the MCP server on the official SDK for the 2026-07-28 spec, staying compatible with 2025-11-25 | Backend engineer | 2-4 weeks |
| 4 | Put a gateway in front with per-IP limits plus per-client and per-tenant limits | Platform engineer | 1 week |
| 5 | Log client, tenant, user and tool for every call, and add a revoke action | Backend engineer | 1-2 weeks |
| 6 | Add a client allowlist and a setting for customer admins to allow agent apps | Backend and frontend engineer | 1-2 weeks |
| 7 | Add writes behind an out-of-band confirmation tied to the exact action | Backend and frontend engineer | 2-3 weeks |
| 8 | Test for cross-tenant access, injected agents and token replay, then get an outside pentest | Security engineer and outside tester | 1-2 weeks |
| 9 | Test the connection with every agent client you list | QA or backend engineer | 1 week |
What you still build
- The MCP tools: names, descriptions, argument schemas and output trimming
- Tenant scoping from token claims, with tests that try cross-tenant access
- A pending-action record and an out-of-band confirmation page bound to a hash of the arguments
- Rate limits and quotas keyed by client and tenant
- Customer-facing controls: allowed agent apps, activity log and revoke
- Compatibility testing across MCP spec versions and agent clients
Gotchas
- The MCP 2026-07-28 spec deprecates Dynamic Client Registration in favor of Client ID Metadata Documents. Allowlist known client URLs instead of opening registration.
- If the agent receives the confirmation prompt, an injected agent can approve its own action. Send the confirmation to the user out of band.
- Gateways see MCP as one JSON-RPC endpoint, so your MCP server has to validate tool arguments.
- Never trust a tenant or account ID passed in tool arguments. Take it from the token.
- Per-client rate limits on Cloudflare need Enterprise Advanced Rate Limiting or your own code.
- Client support for the spec varies. Users report Claude Code working where the claude.ai web connector fails, so test each client.
- The 2026-07-28 spec removed sessions and the initialize handshake. Older SDKs and docs may still assume them.
Common use cases
- MCP server for your product
- Agent-ready public APIs
- Customer automations and integrations
- Partner and marketplace agents
Key risks
- Long-lived API keys pasted into agent configs
- Prompt-injected agents calling your tools
- Over-broad scopes across tenants
- An injected agent approving its own action
Fast path
- KEEPOAuth with scoped, short-lived tokens
- KEEPRead-only tools first
- KEEPAllowlist known clients. No open dynamic registration
- KEEPPer-client rate limits
- DEFERAgent behavior analytics until volume grows