We serve the world's largest retailers, so leaking one customer's pricing data to another is not an option. Turning our pricing engine into an MCP server - consumed by our customers' agents and our own internal ones - meant re-earning, tool by tool, the trust boundaries our backend had spent years hardening.

Some agents arrive machine-to-machine; others come through Claude, where a human logs in and delegates. Two front doors, one gateway that decides who sees what, on whose behalf, and with which scopes. I'll walk through the decisions that held up and the ones that broke: why we dogfooded the MCP internally before exposing it to customers; why a bare "not found" is a security-relevant bug (it made the agent conclude the whole server was gone, then start improvising); why fewer, flexible tools beat a 1:1 mirror of your API, for blast radius as much as for cost; and why every tool description is untrusted input that ships straight into someone else's model context.

You'll leave with a threat model and a practical playbook for putting an MCP in front of a live multi-tenant product: tenant isolation that survives an agent's creative parameter guessing, authorization that works across both M2M and delegated-user paths, rate limiting for clients that retry in a loop, and error semantics that let an agent recover without telling an attacker anything. Plus the war stories behind each decision.