MCP for SaaS Products: Do Not Give an AI Agent Your Admin Panel

The fastest MCP demo is also the most dangerous: connect an AI client to the same internal API used by the super-admin panel, expose a generic request tool, and celebrate when the model updates a customer record.

That proves connectivity. It does not prove the product is safe. A production MCP server is a new trust boundary where untrusted natural-language intent becomes privileged software action.

Why this is urgent now

The July 28, 2026 MCP specification release introduced a stateless protocol core, cacheable list results, an extensions framework and authorization hardening. The ecosystem is maturing quickly, which makes implementation discipline more important—not less.

MCP helps a client discover resources, prompts and tools. Your application still decides which tenant is active, which records a user may access, whether an action needs approval and how to reverse a mistake.

Never expose the database as the product interface

A tool named run_sql or call_api delegates policy to a generated string. It is difficult to constrain, hard to explain to a user and nearly impossible to test as a finite product surface.

Expose business capabilities instead: find overdue invoices, summarize an order, draft a refund, reschedule a delivery, add an internal note. Each tool gets a typed schema, a narrow permission, domain validation, rate limits and a predictable audit event.

Resolve tenant context on the server

Do not accept tenant_id from model-generated arguments and trust it. Derive allowed tenants from the authenticated principal and session. If switching organisations is supported, make it an explicit, visible context change and verify membership again.

• Filter every query by server-resolved tenant context.
• Namespace caches, files, vector indexes, queues and analytics by tenant.
• Return minimal fields; a tool response is another data-exfiltration surface.
• Test cross-tenant identifiers, stale membership and revoked access.

The existing SaaS permission-model checklist is the prerequisite. MCP should reuse those roles and entitlements, not invent a parallel authorization system.

Use the MCP authorization boundary properly

The MCP authorization specification requires protected servers to validate that access tokens were issued for the MCP server and explicitly forbids token passthrough to downstream APIs. The specification also calls for HTTPS, PKCE and resource indicators in the relevant authorization flows.

The official security best-practices guide explains the confused-deputy, token theft, SSRF and audit problems created by weak proxy designs.

When the MCP server calls an upstream service, obtain a separate, appropriately scoped upstream credential. Do not forward the client token and hope every downstream API interprets it safely.

Split reads, drafts and commits

Not every tool needs the same friction. Reading a public catalog is different from issuing a refund or suspending a vendor.

Read tools

Use field minimisation, tenant filtering, rate limits and redaction. Sensitive reads should still require specific scopes.

Draft tools

Let the agent prepare a proposed response, refund or schedule change without committing it. Return a deterministic preview including affected records, totals and policy warnings.

Commit tools

Require a recent approval token tied to the action digest. Revalidate state at execution time because prices, roles and order states can change between preview and approval.

Make every write idempotent and reversible where possible

Models and clients retry. Networks time out after the server commits. A duplicated tool call must not issue two refunds or create two shipments. Accept an idempotency key, store the result and return the original outcome on replay.

• Prefer status transitions to destructive deletion.
• Record previous and next state for operator-visible changes.
• Use compensating actions where true rollback is impossible.
• Put financial and security actions behind stricter approval and velocity limits.

Log the decision, not just the HTTP request

An audit record should identify the user, tenant, MCP client, tool version, validated arguments, permission decision, approval evidence, affected objects, outcome and correlation ID. Avoid storing raw secrets or unnecessary sensitive model context.

Operators need a timeline that answers: what did the agent propose, who approved it, what policy ran, what changed and how can we contain or reverse it? If the answer requires reconstructing model logs from three vendors, the control surface is incomplete.

A production readiness test

1. Attempt cross-tenant reads with valid IDs from another organisation.
2. Replay the same write after a simulated timeout.
3. Revoke the user between preview and approval.
4. Inject a URL, hidden instruction and oversized payload into tool arguments.
5. Verify that support can trace and contain every completed action.

The goal is not to give an AI your admin panel. It is to turn carefully selected product capabilities into a smaller, typed and auditable interface. That makes the agent useful while keeping authority inside the SaaS product you already know how to secure.