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:
Aggregate metrics
Header panels summarize fleet-wide activity and TDX capacity:
| Panel | What it shows |
|---|---|
| Total Sandboxes | All-time sandbox count |
| Total Compute Min | Cumulative compute minutes across all sandboxes |
| Today's Sandboxes | Sandboxes created today |
| Today's Compute Min | Compute minutes consumed today |
| Running Now | Sandboxes currently active |
| Active CPU Cores | vCPU cores in use right now |
| Active RAM | Memory in use right now |
| Active Storage | Disk in use right now |
Capacity vs. consumption
Three ring gauges, VCPU, RAM, STORAGE, show current usage against total TDX node pool capacity (for example, 72 / 4.0k vCPU, with the percentage free called out below each ring). Use this to see at a glance how much confidential compute headroom the fleet has left.
Node pools
Scanner displays the underlying confidential-compute node pool configuration, each tagged with a TDX badge:
| Pool | Machine type | Purpose |
|---|---|---|
tdx-us-central1 | c3-standard-4 | General TDX workloads |
control-tdx | c3-standard-4 | Control plane (fixed scale) |
sandbox-c3-44 | c3-standard-44 | Sandboxes (Ubuntu 24.04 LTS) |
Each pool row lists vCPU/RAM, boot disk (pd-balanced), autoscale range, and availability zones.
Daily Compute Minutes
A bar chart at the bottom of the page plots compute-minute consumption per day, so you can spot usage spikes or a sandbox left running.
Inventory table
Below the charts, the sandbox inventory lists individual environments:
| 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) |
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