Trusting third-party servers

Read these first

• Multi-tenant servers

What you will know

• Review a third-party server before installing it

  Inspect its source, dependencies, permissions, credential handling, and outbound destinations rather than trusting its documentation or registry listing.

• Trace a server's token, filesystem, and network access in a sandbox before granting production credentials

  A harmless-looking tool can inherit broad host access or forward sensitive context through an unexpected dependency or endpoint.

• Write an installation policy that rejects servers with specified provenance, permission, or egress gaps

  Predefined rejection criteria prevent delivery pressure from turning an unresolved trust question into an exception.

• Run an untrusted server with least-privilege credentials and deny-by-default filesystem and network access

  Isolation limits what an exploited process can read or contact, but it does not make malicious behavior safe by itself.

• Reproduce a compromised-server scenario and verify that logs, egress controls, and token rotation limit the blast radius

  A tabletop policy is insufficient if you cannot detect attempted exfiltration and revoke the exposed access quickly.

Chapters

1. 1

   What installing a server grants

   Twelve thousand stars, an MIT licence and a recognisable company describe the packaging, not the request. Four lines of JSON start a process running under the developer's own uid, holding whatever tokens the parent environment leaked into it — 72 variables on one CI runner where exactly one was in the config — and seeing every checkout on the disk. Unlike a library it also participates in the agent's loop, with outputs that steer the model, and `@latest` means you cannot name the code you reviewed.

   Read chapter
2. 2

   Source review before an install

   Reading a candidate server's source has two possible outcomes, and only one is a configuration change. A broad filesystem default or a dependency you would rather not carry changes how you run it; a server that posts tool-call arguments to its own telemetry endpoint ends the conversation. Findings about what the code fails to do are configurable; findings about what it intends to do are not. The order that makes two hours enough is source, dependencies, permissions, credential handling, outbound destinations — and registry listings are not evidence.

   Read chapter
3. 3

   Sandbox tracing a candidate server

   Run the candidate in a sandbox and record egress, filesystem reads, child processes and the environment it touches. The observation that should move your decision most is an outbound connection to a host that is not the API it wraps — on one server, 4,182 bytes to an insights host twenty-seven minutes into an idle stretch. The negative result deserves an honest reading: six of fourteen tools across forty-one invocations and forty minutes of process lifetime is what a clean run covers, and interesting behaviour is conditional by construction.

   Read chapter
4. 4

   Isolating a server process

   A read-only mount of one repository, egress allowlisted to the vendor's API, a token scoped to a single project and a pinned image digest cut the reachable surface from 72 environment variables and 61 checkouts to three variables and one repository. That is real containment and it bounds what an exploited process can reach. It does not bound the permitted behaviour: a 9.4 MB repository leaves as 210 issue bodies through the one allowed host in a little over two minutes, and nothing at this layer separates abuse from use.

   Read chapter
5. 5

   Servers that relay external content

   Every control so far constrains what the server's process can read, reach and hold, and none of them touches the property that makes an MCP server unlike a library: it sits inside the agent's loop, and the text it returns is read by a model that then acts. A server relaying issue bodies written through a public portal is a conduit, and its own code can be impeccable. That residual is why the install decision needs a second axis — which loops the server may sit in, and how much authority the agent holds while it runs there.

   Read chapter
6. 6

   Rejection criteria for third-party servers

   A checklist of ten security properties a server should have is evaluated at the worst possible moment, by the person with the most to lose from a no, against criteria that are all matters of degree — and it gets waived eleven minutes before a launch. What holds is the inverse: named provenance, credential-handling and egress gaps that mean no, written before any particular server is on the table, each naming the artefact that settles it, with a named person and a 90-day expiry on every exception.

   Read chapter
7. 7

   Running a blast-radius drill

   Fork the server, add twenty lines that post every credential in its environment to a host you control, run it exactly the way production runs it, and watch what your egress controls and alerts actually do. On one hardened profile the HTTPS channel died in 0.3 seconds and DNS carried the whole environment out in 47 lookups over 2.1 seconds, with no rule matching either. Then rotate what leaked and time it: two credentials cost zero minutes and one took 96.

   Read chapter