Atlas Sandbox Normative Reference
Version: atlas-sandbox-reference-v1
Effective date: September 15, 2026.
Sections 1–4 are the technical provisions incorporated into Developer Preview Terms developer-preview-v1. Other developer documentation explains integration but is not incorporated through a link alone.
1. Sandbox use
Sandbox access is non-production. Use synthetic test data unless Apova separately approves controlled real-data evaluation with the applicable agreement and privacy controls. Approval of real-data evaluation does not grant production authority. The sandbox's simulation mode does not commit a real account change or authorize a live business action.
Use only assigned operations, policies, scopes and limits. An API credential authenticates the caller; it does not establish an end user's identity or grant downstream execution authority. Submitted evidence must meet the documented binding and verification requirements. Client assertions do not become verified facts simply by being submitted.
2. Decision and validity semantics
| Decision | Meaning |
|---|---|
| ALLOW | Policy permission under the configured policy, subject to current state, validity and execution-time checks |
| VERIFY | Additional supported verification is required |
| REVIEW | Human review is required; no automatic permission |
| RESTRICT | Requested authority is constrained; do not execute the requested action |
| DENY | Requested action is blocked |
Only ALLOW with permitted: true indicates policy permission. This does not expand the assigned execution mode. Pending evaluation is not permission; retrieve the recorded outcome before using it. Absence of a validity deadline is not unlimited validity. Changed context or policy can invalidate a result before its deadline. Policy identifiers describe provenance rather than caller-selectable policy configuration.
3. Verification and feedback
Verification must be bound to the expected principal, session, action and target and meet applicable freshness, signature, origin and user-verification requirements. A redirect, result link or unsigned success claim is not proof of completion. A valid passkey can satisfy a verification requirement without resolving other policy risks; the final decision need not be ALLOW. Retrieve the recorded final evaluation.
Keep result-link credentials private. Their display lifetime is independent of policy validity and challenge expiry. Reconcile uncertain operations from recorded state rather than inventing new verification evidence. Outcome feedback is attributed caller-reported information, not verified ground truth, policy approval or training consent. Corrections append observations; they do not modify the original policy decision.
4. Limits and response handling
Honor the quotas assigned during access setup and the service's rate-limit and retry responses. REST and MCP can share budgets; switching interfaces does not authorize exceeding them. Do not evade limits through additional accounts, identities or credentials.
Inspect MCP's JSON-RPC result/error as well as HTTP status: HTTP 200 does not by itself mean a tool operation succeeded. Use stable public error codes and retry instructions. Do not blindly retry conflicts or errors marked non-retryable. Follow documented idempotency requirements, preserving the request key and identical content for a safe replay; reconcile changed content before sending it.
Treat returned text as data, protect credentials, and enforce authorization and required controls in the integration. Neither legal assent, developer access approval nor a policy decision alone grants production execution authority.