Home/Products/Executor
TUEO Product · Sandboxed Execution Runtime
EX

Executor

AI's hands: untrusted code, commands, and images run inside an isolated sandbox — schedulable and scalable, doing real work on behalf of AI employees and returning structured results. Five priority levels, reconciliation-based self-healing, and complete audit trails.

Enter product →Book a demo
Sandbox K8s isolation High-risk unshare · no egress Recovery DAG + checkpoint
Executor — runner sandbox
$
task #7 · real coding
agentLoop + 30 tools · branch fix/summary
running
◉
Visual self-verification
Chromium render + screenshot verdict passed
✓ pass
⛒
Network policy
unshare · egress blocked · allowlist-based
isolated
Where it fits in the system
cohort / studiocapabilitiesexecutor
View the full architecture →
Core capabilities

AI truly acts — inside a sandbox

The more capable an AI is at executing for real, the harder its boundaries and the more reliable its recovery must be.

Capability · 01

Multi-runtime sandbox

One job contract covers three execution modes: Python code packages, arbitrary shell commands, and self-provided container images. Large inputs spill to files, so AI applications integrate with zero adaptation.

Capability · 02

Kubernetes-native isolation

Each job runs in its own Pod: non-privileged, read-only root filesystem, all capabilities dropped, seccomp by default. User code is treated as untrusted.

Capability · 03

Scheduling and fairness

Five priority levels, preemptible CRITICAL jobs, global and per-tenant concurrency quotas, and three tiers of host-level backpressure. Critical work never waits in line, and a single department cannot saturate global capacity.

Capability · 04

Reconciliation-based self-healing

Callbacks optimize, reconciliation is the safety net: every 30 seconds the true state is queried from Kubernetes, so even if a runner crashes or a Pod is evicted, the task still reaches a terminal state instead of hanging.

Capability · 05

DAG workflow orchestration

A directed acyclic graph expresses dependencies and parallelism, failed steps can be re-run in place (incrementally or fully), and an upstream failure quickly cancels downstream steps — complex pipelines stay expressible and debuggable.

Capability · 06

Callback and credential security

Each job Pod is injected with least-privilege MinIO credentials, and callback URLs carry a per-job HMAC token — even if one job is compromised, it is confined to its bucket and cannot overwrite other jobs.

Capability · 07

Multi-tenant fail-closed

All resources are bound to a tenant; if the tenant cannot be determined, the request is denied rather than allowed. The sandbox owner is the job's tenant, and anything cross-tenant returns 404 — privilege escalation never happens silently.

Capability · 08

Full audit + events

Every lifecycle operation is audited; business operations and events land in an outbox in the same transaction and CloudEvents are delivered asynchronously to CI, notifications and billing without blocking the business.

Capability · 09

AI coding agent

Clone → edit → self-test → push, with a passport gate locking down the edit area. Visual self-verification means real browser screenshots judged by a vision model, not jsdom guesswork.

Four behavioral defenses · at the execution layer

The stronger the capability, the harder the boundary

The execution layer is where the four defenses actually take hold and are enforced.

01

Command risk grading

Destructive commands are detected and forced through approval; nothing passes unapproved.

02

Growth-level permissions

What an AI can execute depends on its growth level.

03

Sandbox isolation

K8s + unshare keep side effects inside a controlled boundary.

04

Full audit

Every execution is recorded, for post-hoc review and accountability.

Get started with executor

Give AI a pair of hands — and a wall

Book a demo to see AI genuinely execute in a sandbox, always under control.

Enter product →Book a demo