Security model

A sandbox can run code, commands, and services from sources you do not control. Treat everything inside it according to that level of trust, and keep the credentials used to control PHPSandbox outside the sandbox.

The trust boundary

Code inside a sandbox can read its files, inspect its environment, start processes, and make the outbound requests allowed by its network policy. Assume repository code and commands may be untrusted, especially when a sandbox was created from a pull request, uploaded archive, or user-supplied prompt.

Keep PHPSandbox API keys in the trusted application controlling the sandbox. Do not write them into sandbox files or pass them as command arguments. Rotate a key if it appears in logs or output.

Secrets and credentials

Use sandbox secrets for sensitive runtime values and provider credentials. Secret values are accepted when they are set but are not returned by list operations.

Separate development and production secrets. Never commit generated environment files, access tokens, Git credentials, preview tokens, or Composer credentials to the sandbox repository.

See Secrets and environment for the supported secret types and lifecycle.

Outbound network access

Network policies control requests leaving the sandbox. A deny policy is the safest default for code that does not need the internet. When access is required, allow only the hosts, methods, and paths the workflow needs.

Network rules do not make an exposed credential safe. They reduce where sandbox code can send data, but code can still disclose values through allowed destinations, command output, generated files, or previews.

Previews and sharing

A preview URL exposes a running application, including any routes that application makes public. Use password protection for human review and short-lived sessions or handoffs for automated access. Do not put preview tokens in source code, logs, analytics, or long-lived links.

Before sharing a preview, confirm that debug pages, database tools, mail viewers, and framework diagnostics do not expose sensitive state.

Record useful activity

Create Git checkpoints before automated or risky changes so work can be reviewed or restored.

Capture sandbox IDs, operation names, and non-sensitive error codes in the controlling application's logs. Avoid recording command output or file contents by default because they may contain user data or secrets.