Why access control matters for MCP
An MCP tool that reads your calendar is convenient. An MCP tool that can send emails, modify your CRM, or query a production database on your behalf is powerful — and powerful things need guardrails. Once you connect an AI assistant to real business systems, "which tools can this person's assistant call, and with what data" becomes a real security question, not a hypothetical one.
The core risks
- Over-broad tool access — every team member's assistant can call every tool, including ones meant only for admins (e.g. billing, user management, deletes).
- Prompt injection via tool output — a malicious webpage or document surfaced by one tool can try to instruct the model to call a different, more dangerous tool.
- Credential sprawl — API keys and OAuth tokens for connected services end up copy-pasted into configs with no central place to rotate or revoke them.
What good MCP access control looks like
- Role-based tool sets — define roles (e.g. "member", "admin") and control exactly which tools each role can see and call, not just which servers they can connect to.
- Per-member identity, not shared secrets — where possible, each person authenticates to a connected app with their own account (per-member OAuth), so access follows your existing permissions in that app instead of one shared god-mode credential.
- Centralized env/secrets management — store API keys and tokens in one place with controlled access, instead of scattered across individual configs.
- Auditability — you should be able to see which tool was called, by whom, with what inputs, and what came back.
A simple mental model
Treat MCP tools the same way you'd treat internal API endpoints: assume they'll eventually be called by someone (or something) you didn't fully anticipate, and scope permissions accordingly. Give the least access that gets the job done, and make the risky tools (writes, deletes, payments) the exception that requires an explicit role — not the default.
How Smia approaches this
Smia hubs support role-based access to tools and servers, per-member authentication for connected apps, and hub-level environment variables for shared credentials — so you can share useful AI tools across your team without handing everyone the keys to everything.