eqixiacEquinix Infrastructure as Code

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.

RiskControl
The agent reads data it should notScope the API application; select toolsets
The agent changes or creates resourcesRead-only default; broker with dry run, hash binding and human confirmation; no update or delete tools
Credentials leak through logs or configurationMasked debug logging; .env.local; stderr only
The agent is steered by text inside API dataTreat 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 .gitignore excludes, 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.

UseEQUINIX_MCP_TOOLSETS
Design and costing sessionsdesign
Facility monitoring questionsibx
Operations desk: tickets, billing, devicesportal,ne,ibx
Design plus guarded creates in a sandboxdesign,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 mutate off unless a person reviews every proposal.
  • Try the flow against the sandbox first.
  • Do not set EQUINIX_MCP_ALLOW_UNCONFIRMED_MUTATIONS on 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 portal toolset.
  • 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_id is 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.