Security guidance
Credential scope, toolset selection, mutation controls and logging for the MCP server.
Threat model#
An MCP server lets an agent call APIs with the operator's credentials. The agent's input includes text that the operator did not write, such as ticket descriptions, resource names and web pages the host has loaded, and any of that text can contain instructions addressed to the agent. The controls on this page limit what an agent can do when it follows such instructions.
| Risk | Control |
|---|---|
| The agent reads data it should not | Scope the API application; select toolsets |
| The agent changes or creates resources | Read-only default; broker with dry run, hash binding and human confirmation; no update or delete tools |
| Credentials leak through logs or configuration | Masked debug logging; .env.local; stderr only |
| The agent is steered by text inside API data | Treat tool output as data; keep mutate off where no person reviews proposals |
Credentials#
- Create an API application that only the agent uses, separate from the credentials of production automation. The agent's calls then appear under their own identity in the audit trail, and its key can be revoked without affecting other systems.
- Grant the application the least privilege that covers the selected toolsets. The fourteen read-only tools need read entitlements.
- Store the secret in
.env.local, which the repository's.gitignoreexcludes, or in a per-user host configuration, and rotate it on the same schedule as other credentials. - Debug logging masks
client_secret, passwords and access, refresh and subject tokens in JSON and form bodies. Release 3.0.0 could write them to the log.
Toolsets#
Select the toolsets that the intended use needs.
| Use | EQUINIX_MCP_TOOLSETS |
|---|---|
| Design and costing sessions | design |
| Facility monitoring questions | ibx |
| Operations desk: tickets, billing, devices | portal,ne,ibx |
| Design plus guarded creates in a sandbox | design,mutate with EQUINIX_SANDBOX=true |
The server constructs a domain client only for a selected toolset, so a tool outside the selection cannot be reached by any call.
Mutations#
- Leave
mutateoff unless a person reviews every proposal. - Try the flow against the sandbox first.
- Do not set
EQUINIX_MCP_ALLOW_UNCONFIRMED_MUTATIONSon a host that auto-approves tool calls. - Review every field in the confirmation prompt. The prompt lists notification emails, project and purchase-order identifiers, VLANs and service-token grant settings, because a wrong value in any of them sends notifications, charges or access to the wrong party.
- The broker has no delete tool. A resource created by mistake has to be removed through the SDK or the portal.
Data handling#
- Tool output can contain account numbers, contact names, invoice amounts and network topology. It becomes part of the conversation the MCP host sends to its model provider. Apply the data policy of that provider and of your organization before enabling the
portaltoolset. - The design tools send ASNs to PeeringDB and region names to the cloud providers' public price APIs. They send no account data to those services.
- The plan store and the proposal store are held in process memory and are lost when the server exits. A
plan_idis valid for 30 minutes and a confirm token for 10 minutes.
Operating the process#
- Run the server as the same unprivileged user as the MCP host. It needs no elevated rights and listens on no port.
- Pin the jar by version and checksum in managed environments, and build from a tagged release.
- Keep the stderr output when diagnosing a failure. Each Equinix call logs its
X-Correlation-Id, which Equinix support can use to trace the request.