MCP security is a real conversation. Here's how we scoped ours.

Model Context Protocol servers went from a niche integration pattern to production infrastructure over the past year. AI assistants — Claude Desktop, Cursor, GitHub Copilot, and others — now routinely connect to real business systems and take real actions on them, not just answer questions about them. That shift changed what's at stake. When an MCP server can search a knowledge base, running it carelessly is a nuisance. When an MCP server can deploy an app, spend money, or send a message on a customer's behalf, running it carelessly is a production incident.

The security conversation that's followed is legitimate, not manufactured pushback against the technology. As MCP has moved from demos into production through 2026, the concerns raised consistently across the ecosystem are: servers exposed to the open internet with no meaningful access control, configuration files that get silently modified or poisoned to redirect a trusted assistant toward a malicious server, and authorization schemes bolted on after the fact — separate from, and weaker than, whatever the underlying platform already uses to protect the same data through its normal API.

How our MCP server actually authenticates

We built the Tricknowtech MCP server against that backdrop, so it's worth being specific about what "scoped" means here rather than just asserting it.

The MCP server authenticates with the same Sanctum bearer token used everywhere else on the platform — the identical mechanism the customer portal itself uses to call our API. You generate the token once, from profile settings, and hand it to Claude Desktop, Cursor, or whichever MCP-compatible assistant you're using. There's no separate MCP-specific auth path, no shadow credential system with its own rules, no weaker fallback bolted on for convenience. Whatever access control applies to a normal API request applies identically to a request that arrives through MCP, because as far as the backend is concerned, it's the same kind of request.

That distinction matters because a lot of the "weak authorization" failure mode reported elsewhere in the MCP ecosystem comes from exactly this gap — an MCP layer added on top of an existing system, authenticated separately, checked less rigorously. We didn't build a second front door into the same house.

Scoped to one account, nothing more

39 tools are exposed through the server, covering account, domains, hosting, VPS, billing, email, WhatsApp, and app deployment — enough to actually get work done, not a token gesture toward "AI support." Every one of them is scoped to the data belonging to the account that generated the token. There's no cross-account access and no admin-level surface reachable through MCP, regardless of what the assistant on the other end asks for. An agent connected with your token can see and act on your domains, your hosting accounts, your VPS instances, your invoices — not anyone else's, and not the platform's internal state.

Actions still pass through the same guardrails

The second thing worth being specific about: sending a message through MCP isn't a side door around the checks that apply everywhere else on the platform.

• Email sends made via MCP go through the identical LLM transactional-content check as every other Email API send — the same rule that keeps the whole product limited to transactional mail (order confirmations, receipts, password resets, shipping updates, account alerts) rather than marketing or bulk email. That's an AWS SES production-access condition, not a preference, and MCP doesn't get an exemption from it.
• WhatsApp sends via MCP are limited to send_whatsapp_text, send_whatsapp_template, list_whatsapp_accounts, and list_whatsapp_templates. There's no broadcast tool and no automation-rule trigger exposed through MCP — an agent can send an individual text or template message, and look up accounts and templates. That's the ceiling.

That's a deliberate restriction, not an oversight. Broadcast campaigns and automation rules are the WhatsApp features with the largest blast radius if something goes wrong — segmented recipient lists, rules that fire on their own without a human re-checking each send. Keeping those out of the MCP surface entirely means the worst case for a compromised or careless MCP session is one bad message, not a campaign.

The token is the boundary

Put those three things together and the practical security model is simple, if less exotic than the framing "AI agent security" sometimes implies. The MCP server isn't a separate attack surface with its own novel risks to reason about — it authenticates the same way the rest of the platform does, it can't reach beyond one account's own data, and it can't do anything through a send tool that the equivalent dashboard action couldn't already do. What's left is the one credential that unlocks all of it.

This is also why the "poisoned configuration file" failure mode discussed elsewhere in the MCP ecosystem is worth taking seriously even though it isn't a Tricknowtech-specific mechanism — it's a risk to whatever holds your token, not to any one server's code. A config file pointing your assistant at a server you didn't intend to trust doesn't need to break our authentication to cause damage; it just needs your token to end up somewhere you didn't put it. Account-level scoping limits what that damage can be once it happens. It doesn't replace the basic discipline of controlling who, and what, has the token in the first place.