Key Takeaways
- Multi-tenant MCP for SMS means one tenant cannot list devices, send, or read DLR belonging to another — keys, allowlists, and logs must not mix.
- We are not a turnkey white-label “sell SMS” marketplace; custom branding only when contracted.
- HMAC per webhook endpoint; least-privilege keys per tenant env — never a shared god key in one MCP process for all customers.
- OEM + plan caps apply per account/device pool; no Unlimited SMS titles.
- Developer Center owns live REST fields.
- BYO Android and operator credit per operator of each handset. We meter devices and volume (Free 300 lifetime; paid from $19/mo).
Summary
Security for multi-tenant MCP SMS considerations is isolation: credentials, device pools, webhooks, and audit trails. Concepts: multi-tenant concepts. Spec: modelcontextprotocol.io. REST: Developer Center.
If the agent can pick any deviceId across customers, you did not build multi-tenant MCP. You built a shared SIM farm with a prompt.
Tenant boundary first
Resolve tenant from authenticated MCP session — not from a free-form tool argument the model invents. Device lists, send, and status tools inherit that binding. No first-party multi-tenant MCP SaaS from us; your control plane owns tenancy. Product overview.
Context
Agencies and internal platforms want one MCP host for many clients. That pattern only works with hard walls: separate keys, separate webhook secrets, and logs that cannot join on message body across tenants.
Isolation rules
- One gateway API key (or vault path) per tenant; never a global send key in shared MCP memory.
- deviceIds validated against the tenant’s allowlist before REST.
- Webhook endpoints and HMAC secrets are per tenant.
- Tool results omit other tenants’ metadata even on error paths.
- Avoid white-label “sell SMS credits” framing — meter devices + volume honestly.
Isolation table
| Asset | Per-tenant? | Cross-tenant smell |
|---|---|---|
| API key | Required | One env var for all customers |
| Device pool | Required | Agent-supplied arbitrary deviceIds |
| Webhook HMAC | Required | Shared secret across tenants |
| Audit log | Partitioned | Bodies searchable across orgs |
Billing and airtime per tenant
Platform metering is devices + SMS volume per account. Each SIM’s operator airtime is separate. Free/Developer pause on exhausted allowance; OEM ceilings still apply on each handset. Pricing.
Operations
Alert on cross-tenant access denials — they are often probes. Rotate keys on tenant offboarding before deleting MCP registrations. Setup.
HMAC and least privilege
Verify each tenant webhook with its own secret on the raw body. Webhooks. MCP HTTP (if used) authenticates the tenant session separately from gateway Bearer.
Decision guide
Single-tenant MCP per customer deployment is the lowest-risk default. Shared hosts need a formal isolation review — see securing SMS MCP tools.
Checklist
- Tenant bound before any tool runs.
- Keys, devices, HMAC secrets partitioned.
- No shared god-key MCP process.
- No white-label SMS reseller theatre; no Unlimited SMS titles.
- No exploit PoCs; no first-party multi-tenant MCP claim.
Next steps
OTP tool surface: send OTP and verify OTP tools (security).
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- SMS API documentationLive endpoint reference
- device and SMS volume pricingPlans and allowances
- Security and Trust CenterCompliance and posture
- Android SMS gateway product guideDefinition, product, and how to buy
