Why MCP servers need attention
The Model Context Protocol makes it easy to connect AI to tools and data. That ease is the risk. An MCP server often holds credentials to real systems and exposes actions an AI can call on request. A poorly secured server can give any connected AI, or anyone who can reach it, the same access.
MCP standardises how AI clients discover and call capabilities. Deciding who may call what, on which data, remains your job.
Checklist
1. Authenticate clients
- Remote MCP servers should require authentication. The MCP specification describes an OAuth-based approach for remote servers; follow the current specification rather than inventing your own scheme.
- Do not leave a server listening on a network without authentication, even “temporarily”.
- Know which person each connection belongs to, not only which application.
2. Keep upstream credentials on the server
- The server, not the AI or the prompt, should hold tokens for downstream systems.
- Store secrets in a secrets manager or encrypted configuration, not in source code.
- Use a separate, limited credential for each downstream system.
3. Expose narrow tools
- Prefer “list overdue invoices” over “call any accounting API endpoint”.
- Separate read and write tools so they can be allowed independently.
- Do not expose tools you do not need.
4. Validate everything
- Validate tool inputs against strict schemas. Reject anything unexpected.
- Never pass AI-generated text directly into shell commands, file paths or database queries.
- Apply limits on result size, request rate and execution time.
5. Treat retrieved content as untrusted
Documents, emails and web pages can contain text designed to instruct the AI, a problem known as prompt injection. A server cannot fully prevent a model being influenced, but it can limit the damage: restrict which actions are possible, and require approval for anything consequential.
6. Require approval for consequential actions
Sending, paying, publishing and deleting should wait for a person. Build that into the server or the layer in front of it, not into the AI’s instructions.
7. Log every call
Record the person, the client, the tool, the parameters, the decision and the result. Include refused calls.
8. Maintain it
- Keep dependencies up to date.
- Review third-party MCP servers before installing them. They run with whatever access you give them.
- Remove servers nobody uses.
Local versus remote servers
Local servers run on a person’s computer and often use that person’s own credentials. They are convenient for individuals but hard to govern across a team: every machine becomes a place where keys live. Remote servers can be managed centrally but must be properly authenticated and hardened, because they are reachable over a network.
How Kroy approaches it
Kroy exposes one authenticated MCP endpoint to AI clients and sits in front of your business systems. Credentials stay in Kroy’s Connectors. Tools are presented as defined actions and Skills rather than raw access. Every call is checked against the person, the agent, the delegation, policy and approval requirements, and recorded. Instead of securing a separate MCP server for every system and every employee, you secure the boundary once.