The execute tool runs agent-supplied JavaScript in a VM context inside a separate child process. The sandbox is a basic guardrail against bugs and other unexpected behavior in code generated by AI agents. However, it is not designed to contain hostile code and must not be treated as a security boundary against an adversary.

The server assumes that its users and callers are trusted. Therefore, HTTP authentication controls who can connect, but it does not isolate authorized callers from one another. Run mutually untrusted users in separate, independently isolated deployments.

Preventing and mitigating prompt injection is the responsibility of the AI gateway or agent harness, not this MCP server. The server assumes that requests reaching it have already passed those controls and cannot determine whether a tool call reflects the user's intent.

If code escapes the VM context, it may access server credentials, host resources, or data from other calls, subject to the host's protections. Consequently, if the parent server process is compromised, assume that every Fastly token it is processing is exposed. Runtime permission flags and host hardening can reduce specific risks. Nevertheless, they do not turn the sandbox into an adversarial security boundary.

If you supply a Fastly API token to a remote server, its operator can read and use it. Encryption of tool output does not hide the token from that operator.

Remote mode accepts a different Fastly API token on every request and runs code for many callers on one replica. See the remote HTTP deployment guide for host requirements, setup and deployment tests. Even with the Linux extras, none of the defenses below turns the VM context into a containment boundary.

Each execution is a fresh Node child that gets its caller's token on stdin only. Nothing is shared between executions except the server process that started them. Bun never runs remote executions, even a version that passes the memory tests.

On Linux, with kernel.yama.ptrace_scope at 1 or higher and no CAP_SYS_PTRACE, a child cannot attach to the server or to a sibling, and cannot read their /proc/<pid>/mem or /proc/<pid>/syscall. On other platforms, or with the setting at 0, the server warns at startup and runs without this protection. Yama does not cover /proc/<pid>/environ, so never put a credential in the server's environment.

Children run under the Node permission model: read access to the installation only, no child processes, no workers, no native addons and no Inspector. However, Node itself says this model does not contain malicious code that already has host capabilities. --allow-net grants the whole network, not a list of hosts.

Executed code has no fetch, the Fastly client only talks to api.fastly.com and rt.fastly.com without following redirects, and file upload operations are refused. Cloud metadata endpoints must be blocked outside the process, for the service user and for the container's forwarding path. The URL restrictions above only cover the supported interface, not code that escaped it.

V8 gets a heap cap on every platform. On Linux, prlimit also caps allocations and CPU time, and each child is marked as the first thing the kernel OOM killer should kill. Both are skipped with a warning when the host lacks them. These limits apply to one execution and do not promise that other calls survive a host that runs out of memory.

Without Yama, prlimit and the OOM score file, a deployment keeps the portable protections: the execution deadline, the output caps, the admission limits and the heap cap. It is still weaker against resource exhaustion, because ArrayBuffers and native allocations are unbounded and CPU time is only limited by the wall clock. It also has no protection against a process that reads the server's memory after a sandbox escape. The startup audit record says which protections are active.

In remote mode, the secret encryption key is derived from the caller's token with HKDF-SHA-256. Each recognized secret is replaced with {ENCRYPTED:...}, which holds the whole encrypted token plus a short check value.

If the key or the tweak is wrong, or the value was changed, the check fails instead of producing a believable token. The check gives about 48.5 bits of protection, assuming the FAST cipher behaves as a strong tweakable pseudorandom permutation. It is not authenticated encryption.

The same secret always gives the same encrypted value under the same key. So anyone who can get a guessed value encrypted with that key can check whether the guess is right.

The encrypted value hides the token's prefix, but its length and the text around it can still show what kind of token it is. It also isn't tied to where it appears, so a valid one can be reused, moved to another argument or removed without anyone noticing.

The feature keeps recognized secrets away from the model, not from the operator of the server.

The server remembers a valid token for at most 60 seconds, so a revoked token can still get in for that long. Fastly still authorizes every real API call.

The fastly/mcp project team welcomes security reports and is committed to reviewing them promptly.

Before submitting a report, confirm that the issue crosses a trust boundary enforced by this server and is reproducible in a supported deployment. Reports are most useful when they show how an untrusted party bypasses server authentication or another documented protection.

By contrast, an authorized user deliberately passing hostile code to execute is outside this project's security model. Prompt injection scenarios and deployments where mutually untrusted users share one server are also outside its scope because those risks must be handled by the AI gateway, agent harness, or deployment isolation.

Please report security issues privately through Fastly's security issue reporting process.

The project team prioritizes the remediation of security vulnerabilities. When third parties are involved, the team works to coordinate remediation while remaining transparent throughout the disclosure process.

The Fastly team announces security issues in release notes and GitHub Security Advisories on a best-effort basis. These communications about Fastly-maintained open source projects are distinct from Fastly Security Advisories.