Securing MCP servers in the enterprise. Six controls, and how Kryex applies them.
The Model Context Protocol lets coding agents reach issue trackers, code hosts, wikis and internal services. Each MCP server is a new path into your systems — so it needs an owner, scoped access, approval before use and an audit trail.
Updated 16 October 2026
MCP servers are usually governed by no one.
In most setups, a developer adds an MCP server to a local config file, pastes in a token, and the agent can call every tool that server exposes — with that person's full permissions, and without security ever seeing it. Tools can also change upstream after they were first reviewed.
Securing MCP means moving that decision from each laptop to one governed place. Here are the six controls that matter, with how Kryex Admin applies each one. The full design is in the MCP connectors architecture.
Six controls for securing MCP servers.
Register servers centrally, not on laptops
Every MCP server should have an owner and live in one registry, so security knows what exists and can revoke it in one place.
Admins register organization MCP servers once in Kryex Admin. Every MCP call runs from Kryex Server; the desktop only sends which tool and which arguments.
Keep credentials off developer machines
Tokens in local config files leak, outlive the person who created them and can't be rotated centrally.
Credentials are encrypted per organization on Kryex Server, bound to the organization's ID, and no API ever returns a stored secret.
Approve every tool before anyone can use it
A server can expose dozens of tools, from reading an issue to deleting a repository. Each needs a risk decision.
Discovered tools start quarantined. An AI suggests a READ, WRITE or ADMIN tier, a keyword-based floor stops it understating risk, and an admin approves.
Grant access per person, per tool
Access to a server shouldn't mean access to every tool on it.
READ, WRITE and ADMIN are granted independently per user and per tool. Default is deny, and "Requires approval" holds a call until an admin approves exactly that call.
Catch tools that change after approval
An approved tool whose definition changes upstream is no longer the tool that was reviewed.
Kryex stores a hash of each tool's input schema. If it changes, the tool goes back to quarantine until it's re-approved.
Audit every call
Incident response needs to know who called which tool, when, and what was decided.
Every decision is written to a hash-chained, append-only audit log, with arguments stored only as a hash.
Common questions.
What are the main security risks of MCP servers?
The main risks are servers added without review, credentials stored on developer machines, tools with broader permissions than the task needs, tools whose behaviour changes after they were approved, and calls nobody can audit afterwards.
How do you govern MCP tools in an enterprise?
Register servers centrally, keep their credentials on a server rather than laptops, approve each tool with a risk tier before use, grant access per person and per tool, re-review tools that change, and log every call. Kryex Admin does all six.
Can I block a single tool on an MCP server?
Yes. In Kryex, access is granted per tool, so a person can use some tools on a server and not others. For personal connectors, admins can turn a connector off for the organization or block individual tools.
What happens if an MCP tool changes after it was approved?
In Kryex, each tool's input schema is hashed at discovery. When a later discovery finds a different hash, the tool is quarantined again and can't be used until an admin re-approves it.