Sandboxes
Inspect confidential compute sandboxes and Intel TDX attestation at /sandboxes.
ORGN Scanner is not Studio Code Security (Shannon). Scanner audits Gateway inference attestation and confidential compute sandboxes — it does not scan your repository for CWE vulnerabilities. For code security assessments, see Code Security.
Sandboxes in ORGN Scanner shows confidential compute environments provisioned on Intel TDX hardware via Daytona. Open the inventory at:
https://scanner.orgn.com/sandboxesDevelopment: dev.scanner.orgn.com/sandboxes
Sandbox attestation is public — no sign-in is required to view the sandbox list or inspect TDX attestation evidence for any sandbox.
What sandboxes are
A sandbox is an isolated confidential compute environment — a Trust Domain running on TDX-enabled node pools. Sandboxes back:
- Studio project execution environments
- Gateway development and testing workloads
- Agentic workflows that require a verifiable compute boundary
Sandbox attestation answers: "Is this compute environment running on genuine Intel TDX hardware with the expected measurements?"
It does not answer: "Did a specific inference call run inside this sandbox?" For per-request proof, use inference attestation receipts at /request/:requestId.
Sandbox list page
The /sandboxes page shows:
Inventory table
| Column | Description |
|---|---|
| Sandbox ID | Short alphanumeric identifier — links to /sandboxes/:sandboxId |
| Status | Running, stopped, or archived |
| Created | Provisioning timestamp |
| Resources | vCPU, memory, and storage allocation |
| Team | Owning team (when visible) |
Aggregate metrics
Header panels summarize TDX capacity and utilization:
- Active sandbox count
- vCPU, RAM, and storage usage vs. TDX node pool capacity
- Distribution across TDX node pools (
tdx-us-central1,control-tdx, etc.)
TDX node pools
Scanner displays the underlying confidential-compute node pool configuration:
| Pool | Machine type | Confidential | Purpose |
|---|---|---|---|
tdx-us-central1 | c3-standard-4 | Intel TDX | General TDX workloads |
control-tdx | c3-standard-4 | Intel TDX | Control plane services |
Each pool specifies vCPU/RAM, boot disk, autoscale range, and availability zones.
Sandbox detail page
Navigate to /sandboxes/:sandboxId for per-sandbox inspection:
- Sandbox metadata and lifecycle state
- Resource allocation and runtime duration
- TDX attestation panel — live Intel Trust Domain quote from the Daytona attest-gateway
The attestation panel fetches fresh evidence on each load. A force query parameter is accepted for backwards compatibility but is a no-op — every call returns a live attestation.
Attestation evidence
The sandbox attestation panel exposes the same public verifiability primitive served by the Daytona attest-gateway viewer. Evidence includes:
- Intel TDX quote with VM measurement state
- Verification status against Intel DCAP roots
- Timestamp of the attestation capture
Copy artifacts for compliance archives or re-validate independently against Intel's public PKI.
Sandbox attestation vs inference receipts
Scanner tracks two attestation systems. Do not conflate them:
| Sandbox TDX | Inference receipt | |
|---|---|---|
| Question | Is the environment genuine? | Did this call run in a TEE? |
| Scope | Per sandbox | Per request |
| Source | Daytona attest-gateway | NEAR AI / Phala providers |
| Page | /sandboxes/:sandboxId | /request/:requestId |
| Auth | Public | Public |
See Attestation reference for the full field breakdown.
Public access model
Sandbox attestation is intentionally public. TEE attestation is a verifiability primitive — restricting it behind authentication would undermine the compliance value. Anyone with a sandbox ID can inspect its TDX evidence, matching the behavior of the Daytona public attest-gateway viewer.
Optional id-orgn SSO may unlock team-scoped sandbox management actions (where your role permits), but viewing attestation evidence never requires a session.
API access
Scanner proxies sandbox data through its own API routes:
| Endpoint | Purpose |
|---|---|
GET /api/sandboxes | Sandbox inventory list |
GET /api/sandboxes/stats | Aggregate capacity metrics |
GET /api/sandboxes/:sandboxId/attestation | Live TDX attestation evidence |
The attestation route calls the Daytona attest-gateway directly:
GET {DAYTONA_ATTEST_GATEWAY_URL}/api/sandbox/{sandbox_id}/attestationNo Gateway console token or user session is required.
Explorer integration
The Explorer homepage shows a running-sandbox count when Daytona is configured. Click through from the Explorer to /sandboxes for the full inventory and attestation panels.
When sandboxes are unavailable
If DAYTONA_ATTEST_GATEWAY_URL is not configured in the deployment environment, the sandbox pages return a service-unavailable state. Inference attestation at /request/:requestId is unaffected — it uses a separate pipeline through Gateway spend logs.
Next steps
- Attestation reference — both attestation systems explained
- Verify a request — per-request inference verification
- Scanner Quickstart — guided walkthrough
- Gateway console sandboxes — provisioning sandboxes from the Gateway console