A new MCP server can look harmless in a demo. It exposes tools, returns tidy JSON, and unlocks a workflow. Without quarantine, that first install may run with the same write scope as production agents. Start every new server behind a read-only profile so discovery cannot widen blast radius before policy review.
Treat New Servers as Untrusted at First
Vendor docs explain capability; security review needs constraints. Spin the server in a profile that can list and read only. Deny file writes, shell, deploy hooks, and secret stores on day one. This matches the spirit of how you freeze tool allowlists per environment, not per chat.
Define the Read-Only Profile Explicitly
Define the profile as code: allowed tools, denied tools, network egress, and data classes. Prefer fail-closed defaults. If a tool claims it only reads but can mutate state, keep it denied until proven. Store the profile next to the agent config so reviewers see the same artifact engineers run.
Run Discovery Workloads Only
In quarantine, exercise list, get, and search paths. Log every tool call. Capture schemas and side-effect claims. Do not connect it to customer data. Do not point the server at production tickets. Isolation here rhymes with how you isolate sandbox egress before tool-calling agents roam.
Promote With a Human Gate
Promotion to write scopes requires a named reviewer and a ticket. The gate asks what writes are required, which environments, and how rollback works. High-impact tools stay gated the same way you require human gates on high-impact agent write tools.
Keep Secrets Out of Early Sessions
Quarantine sessions should never carry production tokens. Use stub credentials or empty vaults. If the server demands a key to start, use a disposable scoped key that cannot touch real systems. That keeps the accidental paste problem away from live context packs, as in how you keep agent secrets out of live session context packs.
Retire Abandoned Quarantines
Old, half-trusted servers linger. Weekly, delete profiles that never earned promotion. Document why a server failed review. A short deny log is better than a quiet folder of forgotten MCP configs that someone reconnects under deadline pressure.
Document the quarantine outcome in the same ticket that requested the server. A clear pass or fail note stops the next engineer from reopening write scopes because “it worked in my chat.”
If a vendor pushes for immediate write access to “unlock the demo,” keep the demo on synthetic data inside quarantine. A delayed demo wow is cheaper than an early incident report.
Add quarantine status to the agent inventory sheet: candidate, read-only trial, write-approved, or rejected. Inventories prevent shadow installs from living only in one laptop’s config.
FAQ
What is a read-only MCP profile?
A config that allows discovery and read tools only, with writes and sensitive egress denied.
Can I skip quarantine for internal servers?
No. Internal still means unreviewed until the profile proves scope.
How long should quarantine last?
Until schemas, side effects, and required writes are documented and gated.
What logs matter most?
Tool name, arguments class, success or failure, and whether any mutation was attempted.
Who approves write promotion?
A named human owner, not the chat that first installed the server.
What if the server cannot start without write tools?
Keep it denied or run it only in a disposable sandbox with fake data until redesign.