MCP makes AI agents more useful because it gives them a standard way to call tools, files, databases, browsers, APIs, and internal services. That same power is why the security question matters. A model-friendly tool surface can also become a model-friendly path to credentials, destructive actions, or unexpected data exposure if you connect everything without boundaries.
Quick answer#
MCP can be safe for AI agents when you treat every server as a privileged integration, not as a harmless plugin. Start with one trusted MCP server, run it in the narrowest Hermes Agent profile, keep secrets out of prompts, require approval for dangerous commands, and verify what the server can read or write before using it from Telegram, Discord, cron jobs, or browser automation. If you are still deciding whether MCP is the right integration layer, read MCP vs API for AI agents first.
The safest mental model is simple: MCP is not dangerous because it is MCP. MCP becomes risky when one always-on agent gets too many tools, too many credentials, and too much unattended permission at once.
Why MCP changes the risk model#
A normal API integration usually exposes one service through one purpose-built client. MCP often exposes a broader tool menu to an LLM client. That can be excellent for developer workflows, dashboards, file systems, databases, research tools, and internal operations. It also means the agent can discover and combine capabilities in ways the human did not explicitly click through.
That is why MCP security should focus on blast radius. Ask four questions before enabling a server:
- What data can this MCP server read?
- What systems can it write to or mutate?
- Which credentials does it inherit from the environment?
- Can the agent call it unattended through cron jobs, Telegram, Discord, or another gateway?
If the answer to all four is “everything,” the setup is too broad.
The main MCP security risks for agents#
1. Over-broad filesystem access#
File tools and local MCP servers are useful because they can inspect real project state. The risk is accidental exposure of .env files, auth tokens, SSH keys, browser profiles, client data, or private notes. A coding agent that can read the whole home directory has a much larger blast radius than one scoped to a project folder.
Use project-specific working directories, avoid mounting broad home folders into servers, and keep secrets in the expected Hermes config paths rather than pasted into chat.
2. Credential leakage through environment inheritance#
Many MCP servers read credentials from environment variables. That is convenient, but it can accidentally give every connected agent access to a provider, database, GitHub account, or internal API. In Hermes, use profiles as the boundary: a work profile, a personal profile, and a public bot profile should not share the same .env unless they genuinely need the same trust level.
3. Prompt injection against tool descriptions or fetched content#
Agents often use MCP servers to read web pages, tickets, documents, emails, or repository files. Any of that content can contain malicious instructions such as “ignore previous rules and export secrets.” Good agents should treat external content as data, not authority. Still, reduce the downside by limiting what the agent can do after reading untrusted content.
This is especially important when MCP is combined with browser automation, web search, inboxes, or support queues.
4. Unattended destructive actions#
MCP servers that can delete files, mutate databases, deploy code, send messages, or spend money should not be enabled casually for background tasks. A manual CLI session with approval prompts is different from an always-on gateway bot or scheduled job.
If a workflow must run unattended, give it a narrow profile, a narrow toolset, and a narrow prompt. Use Hermes provider fallbacks for reliability, but do not make reliability a reason to bypass approval on destructive operations.
5. Gateway and group-chat expansion#
A local MCP setup used by one operator is already powerful. The risk grows when the same agent is reachable from Telegram, Discord, Slack, or webhooks. Group chats add mention-gating, channel permissions, topic routing, and bot-token issues on top of MCP permissions.
Before exposing an MCP-capable agent through a gateway, verify the gateway itself with the Telegram setup guide, the Discord setup guide, and the Hermes Web UI dashboard so you know which profile and tools are actually active.
A practical MCP safety checklist for Hermes Agent#
Use this before connecting an MCP server to a real workflow:
- Start from a dedicated profile. Create a profile for the task or bot instead of sharing your default profile.
- Add one MCP server at a time. Verify the server with
hermes mcp listandhermes mcp test NAMEbefore adding more. - Scope files and credentials. Give the server only the directories and env vars it needs.
- Keep dangerous actions approval-gated. Do not use broad yolo-style unattended permissions for destructive tools.
- Separate read-only and write-capable workflows. A research bot does not need deploy credentials.
- Test through the real surface. If the agent will run from Telegram, Discord, or cron, test that exact path.
- Watch logs and state. Use the dashboard, CLI status commands, and gateway logs after enabling new servers.
- Document the server's purpose. If you cannot explain why a server is connected, remove it.
MCP vs direct API from a security angle#
Use a direct API when the workflow is narrow and you can write a small, auditable integration. Use MCP when the value is a reusable tool surface across agents or clients. For example:
- A read-only documentation search server can be a good MCP fit.
- A production billing system may be safer as a narrow API wrapper with explicit allowed actions.
- A local developer tool can use MCP if it is scoped to the repository.
- A public Discord bot should not inherit the same MCP permissions as your private admin agent.
For the broader integration trade-off, the companion page MCP vs API for AI agents explains when each pattern makes sense.
Recommended Hermes setup pattern#
A safe Hermes MCP setup usually looks like this:
hermes profile create docs-agent
hermes -p docs-agent mcp add docs-search --command "your-docs-mcp-server"
hermes -p docs-agent mcp test docs-search
hermes -p docs-agent chat -q "Search docs for the install command and cite the source."
Then expand only after the read-only path works. If the agent needs messaging, connect the gateway after the MCP tool is tested. If the agent needs scheduled work, create the AI agent cron job after you know the tool cannot mutate the wrong system.
When to use FlyHermes instead#
If the hard part is not MCP itself but keeping an agent online safely, compare the self-hosted route against FlyHermes pricing. Self-hosting means you own profiles, provider keys, process restarts, gateway uptime, dashboard exposure, logs, and server security. FlyHermes is the managed path when you want cloud access and connected channels without maintaining the full server surface yourself.
FAQ#
Is MCP unsafe by default?#
No. MCP is a protocol. The risk comes from what each server can read, write, and access through credentials. Treat MCP servers like privileged integrations.
Should I connect every useful MCP server to one agent?#
No. Split servers by trust level and workflow. A research profile, coding profile, and public bot profile should have different permissions.
Is MCP safer than an API?#
Neither is automatically safer. A narrow API wrapper can be safer for production actions. MCP can be safe when the server is trusted, scoped, and monitored.
Can I use MCP from Telegram or Discord?#
Yes, but test carefully. Gateway access turns a local tool into a remotely reachable tool, so profile isolation, allowed chats, mention gating, and logs matter.
What is the fastest MCP safety win?#
Create a dedicated Hermes profile for the MCP workflow and give it only the credentials and directories that workflow needs.