Sandbox Runtime Policy

How Sandbox evaluates requests

Before an action runs, Admissible checks who is making the request, where the action would run, what the action touches, and whether it would make a durable change.

If the request fits Sandbox access, it can continue. If it targets production data, production changes, irreversible changes, external systems, or sensitive resources, Sandbox blocks or defers it.

Responses show the result and the next step without exposing private audit or operator details.

Sandbox access at a glance

Free Sandbox access is intentionally limited so developers can try the runtime safely.

If a risky action is deferred, the response explains why it cannot continue in Sandbox.

A runtime request means a request Admissible evaluates, including execute and commit requests.

How examples behave

• Staging and development read examples are the expected Sandbox happy path.
• Production data reads show the denial path and should not access production data in free Sandbox.
• Production commits and irreversible commits are not available in Sandbox.
• When an action is blocked or deferred, check the response status, message, reset-window details, and nextAction field if present instead of retrying blindly.

What to include in requests

Clear request context helps Admissible make the right decision.

• target environment
• action name
• resource
• action type
• commit type
• supporting operation
• checkpoint or rollback references when applicable

Check your current access

Your account page shows your current access, usage, and policy summary.

If your account includes access beyond free Sandbox, it will be shown there.