MCP security is not a checkbox on a protocol README. It is what happens when an LLM can call tools that touch files, shells, browsers, and SaaS APIs — and someone injects the wrong instruction.
Why MCP expands the blast radius
Without tools, an agent is mostly text. With MCP, it is text plus actuators.
That is the point of MCP — and the risk:
- A "helpful" filesystem tool that can read
~/.ssh - A shell tool that accepts model-authored command strings
- A browser tool that can exfiltrate cookies
- A SaaS connector with write scopes
Prompt injection stops being "the model said something rude" and becomes "the model operated your computer."
Defense in layers (practical order)
- Tenant isolation — do not co-locate untrusted agent tools on a shared kernel with other tenants or your laptop.
- Least privilege tools — enable only the MCP servers the job needs.
- Secrets placement — keys inside the guest, not in a host-wide env shared by every agent.
- Human gates — outbound send, payment, and prod deploy stay human-approved where product allows.
- Audit trail — know what ran; logs that vanish with a container are not enough for incident review.
Protocol hygiene without (1) is rearranging deck chairs.
Where jurniti fits
jurniti gives each agent harness a Firecracker microVM: own kernel, own disk, own network path. You install or enable MCP servers inside that guest. Isolation is the product default, not a paid enterprise add-on.
That does not replace careful MCP allowlists. It means a compromised tool session is a reprovision, not a multi-tenant incident.
MCP server security questions to ask any host
- Can another tenant's process share my kernel?
- Can the platform read my tool tokens?
- Do tool processes survive restarts on a persistent volume?
- Can I destroy and rebuild the box in minutes after an incident?
If the answer to the first two is fuzzy, keep shopping.
Related reading
Plans from $25/mo, BYOK, 30-day money-back on first purchase. No free trial.