Giving Cloud Coding Agents Access to Internal Tools

Map the connection from the cloud to the internal service

A coding task such as fixing a billing regression may need three things beyond the repository: the incident ticket, a deployment record, and a small sample of failing transactions. Design access around those reads. Write down the route from the cloud agent through the MCP endpoint to each internal service, including where authentication happens and which process can reach the service.

The MCP Streamable HTTP specification defines a single endpoint accepting POST requests, with JSON or request-scoped SSE responses. An HTTPS URL gives the client a protocol destination; it does not establish connectivity to a private database behind that destination. Your connection service still needs a deliberately configured route and an upstream identity.

Identify the caller before changing firewall rules. Anthropic’s cloud-environment documentation says enabled MCP connectors travel through Anthropic’s servers, outside the session VM’s network allowlist. Consequently, blocking a domain in the VM does not necessarily block connector access. Review connector permissions alongside VM egress rules.

Expose the evidence needed to change code

For the billing task, start with a ticket lookup, deployment lookup, and bounded transaction-summary lookup. Specify the accepted project, environment, time window, returned fields, and maximum result size for each. A useful result might contain a deployment identifier, an error code, and an aggregated count. It rarely needs the full customer record attached to every failed payment.

Make these restrictions executable at the server and upstream account. For a custom database adapter, select approved views and fields rather than handing the model an unrestricted query interface. For an incident API, allow the relevant project and omit attachments unless the task requires them. These are implementation choices to review with the system owner.

The MCP tools specification requires input validation, access controls, rate limits, and sanitized outputs. It also treats tool annotations as untrusted unless they come from trusted servers. A tool description saying “read-only” therefore needs an enforcement mechanism behind it. Use read-only access by default to define that mechanism before adding a write operation for a later task.

Separate the agent credential from upstream authority

Give the cloud client a credential intended for your MCP endpoint. The endpoint should authenticate that caller, check the requested operation, then use a separate upstream credential with the corresponding system. The MCP authorization specification describes OAuth for HTTP transports and recommends requesting only the scopes required for the operation.

The MCP security guidance explicitly forbids token passthrough: accepting a token intended for a different service and forwarding it downstream crosses an authorization boundary. A gateway must validate its own callers rather than treating possession of any company token as permission to use its tools.

For unattended runs, establish how authentication works before scheduling the task. Confirm whether the provider supports the endpoint’s OAuth flow or a configured authorization header, and who owns that authorization when an employee leaves. Issue separate credentials for independently revocable workloads where supported. Record the task owner, allowed sources, and rotation procedure; the per-agent key guide develops that operating model.

Configure the cloud surface that actually runs the task

Cursor’s Cloud Agent capabilities documentation provides a concrete hosted setup: add a personal server through the MCP dropdown at cursor.com/agents, or have an admin configure a shared server under Dashboard → Plugins & MCPs. Choose HTTP and enter the remote endpoint. Complete OAuth where required; Cursor documents that OAuth remains per-user even for shared servers.

Cursor also documents an important execution difference. HTTP MCP configurations stay outside the VM and calls are proxied through its backend. Stdio servers run inside the VM, where the agent can access their configuration and environment. Choose HTTP when keeping connection credentials out of the VM is a requirement.

For Claude Code CLI in a VM you control, the documented HTTP command is:

claude mcp add --transport http --scope project internal-tools https://mcp.example.com/mcp

Replace the example hostname with your endpoint. Project scope writes the repository’s .mcp.json; the equivalent configuration is:

{
  "mcpServers": {
    "internal-tools": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

This declares the connection, not an authenticated session. In an interactive CLI session, use /mcp to authenticate an OAuth server. Keep credentials out of the committed file. Anthropic’s cloud documentation says a single-repository cloud session loads the repository’s .mcp.json, while local and user-scoped server entries do not carry over. Verify authentication separately on the hosted surface.

Prove the boundary with a disposable cloud run

Use a staging incident and synthetic transaction data for the first run. Ask the agent to identify the deployment associated with the regression and produce a proposed patch. Save an acceptance record with the following checks, including the observed outcome rather than just a pass checkbox:

1. Read the approved incident and deployment. Confirm the returned identifiers match the fixture, and the connection log attributes both calls to the intended caller.
2. Request a second project’s incident. Verify that the server denies access even when the agent supplies a valid identifier directly.
3. Attempt an unavailable write in staging. Confirm authorization rejects it independently of any approval prompt or instruction to the model.
4. Revoke the test credential and repeat an allowed read. Check when enforcement takes effect and whether the provider can silently obtain replacement authorization.
5. Make the upstream unavailable. Confirm the task reports missing evidence instead of presenting an empty result as proof that no regression exists.

Repeat the allowed read from a fresh cloud run. That catches a connection which worked only because a previous VM retained a local configuration or login. If discovery succeeds but invocation fails, inspect the endpoint’s authorization decision and upstream error separately. Do not solve an unexplained denial by broadening the key to every source.

Connect the cloud agent through SPYN3

SPYN3 provides one MCP endpoint per workspace at https://api.spyn3.com/agent/mcp. Connect the required systems, then issue a source-scoped key with call:tools; writes need the separate call:write_tools grant. Upstream credentials stay envelope-encrypted in the workspace and never reach the agent. Calls are audit-logged, and revoking a key takes effect on the next call. Your cloud provider still needs a supported authentication path, and a private upstream still needs a reachable route.

Decide what evidence may leave the internal system

Keeping an upstream password outside the VM addresses credential exposure. The incident text and transaction summaries returned by tools still enter the agent’s working context. Before enabling production reads, decide which fields may be returned and where those results may appear: the conversation, a proposed patch, test output, or a pull-request description.

For the billing example, require the final explanation to reference deployment and incident identifiers without copying payment details into repository files. Review the first proposed change for accidental fixtures containing production records. Treat retrieved ticket text as evidence to assess, including any instructions embedded in it.

Expand access only when the narrow tool set cannot answer a specific coding question. Add the missing lookup, repeat the denial and revocation checks, and keep an owner for the connection after the cloud run ends. For the next review, use the sandbox credential guide to inspect secrets introduced through dependencies, setup scripts, and other paths outside MCP.