Akira Platform Architecture: Hardware-Isolated Sandboxes for Secure Code Execution

The Architecture Question Behind Every Sandbox

When you call a sandbox API, you're asking a deceptively simple question: "Run this code safely."

Behind that request is a stack of decisions. Where does the code actually execute? How is it isolated? What happens to filesystem changes? How do you observe what's running without breaking isolation? And how do you do all of this in under a second?

Most platforms make tradeoffs: containers are fast but share kernels, VMs are isolated but slow, and serverless functions don't give you persistent state or full control.

Akira's architecture is built around a different premise: you shouldn't have to choose between security, speed, and flexibility. Hardware isolation, sub-second cold starts, full filesystem persistence, and network-based observability—all in one platform.

This is how it works.

Platform Architecture Overview

Akira is a multi-layer sandbox execution platform built for secure, multi-tenant code isolation. Unlike traditional container platforms that rely on shared kernel isolation, Akira uses dedicated MicroVMs with hardware-level security boundaries—providing enterprise-grade protection for AI agents, development environments, and automated workflows.

The architecture spans six integrated layers:

Each layer is designed to balance security, performance, and operational efficiency. Together, they enable developers to run untrusted code safely while maintaining the speed and flexibility modern workflows demand.

MicroVM Sandboxes: Hardware-Level Isolation

Every Akira sandbox runs as a dedicated MicroVM with its own guest kernel, isolated behind a hypervisor boundary. This isn't namespace or cgroup isolation—it's hardware-enforced separation.

Dedicated Kernel Per Sandbox

Each sandbox operates with its own Linux kernel. A kernel vulnerability in one sandbox cannot compromise the host or affect neighboring sandboxes.

This eliminates entire classes of container escape vulnerabilities. If an exploit lets code break out of userspace, it hits the guest kernel—not the host. The hypervisor boundary still holds.

Hypervisor Security Boundary

MicroVMs communicate with the host through a minimal interface that exposes an order of magnitude fewer syscalls than traditional container runtimes.

Fewer syscalls mean a dramatically smaller attack surface. There's simply less code for an attacker to target.

Sub-Second Cold Starts

Despite the additional security layer, MicroVMs boot from cold in under one second—including storage mount and network policy application.

That's fast enough for interactive development, AI agent loops, and real-time workflows. You get VM-level isolation without the traditional VM boot penalty.

Dedicated Resource Allocation

CPU and memory are allocated per sandbox with hard limits enforced at the hypervisor level.

This eliminates noisy-neighbor effects that plague shared-kernel container platforms. One sandbox's runaway process can't steal resources from another. Limits are hard, not advisory.

Storage Architecture: Full Rootfs Persistence at Scale

This is where Akira diverges most from competitors. By combining dual-tier storage with a layered filesystem, the platform achieves complete root filesystem persistence without the storage costs typically associated with stateful sandboxes.

Dual-Tier Storage Design

Tier 1: Local NVMe Storage
High-speed local storage on each compute node holds base OS images and container layers. This tier provides microsecond read latency for unmodified system files and is included with compute at zero marginal cost.

Tier 2: Persistent Block Storage
Enterprise-grade block storage provides a dedicated volume per sandbox, handling all write operations. This tier survives sandbox restarts and supports instant copy-on-write snapshots and clones.

How the Layered Filesystem Works

From inside a sandbox, the filesystem appears as a single unified root. But behind the scenes, reads and writes are intelligently routed between storage tiers.

Read Operations:

• Unmodified files (base OS, default configurations) are served from fast local NVMe
• Modified or newly created files are served from persistent block storage

Write Operations:

• All writes go directly to persistent block storage
• First write to an existing file triggers a copy-up from NVMe to block storage
• Subsequent reads and writes use the block storage copy

The Result:
Install packages, modify configurations, or create files anywhere in the filesystem—everything persists automatically. Not just /data or specific mount points. The entire root filesystem is durable, while base-layer reads remain fast and cost-effective.

What This Means in Practice

You can treat sandboxes like persistent development environments. Install dependencies once, snapshot the state, and every clone has those dependencies pre-loaded.

No custom Dockerfiles and no rebuild loops. Just persistent state that works the way a local machine works—except isolated at the hardware level.

Instant Snapshots and Space-Efficient Cloning

Akira captures full sandbox state in seconds using copy-on-write snapshots. Only changes since the last snapshot are stored, making snapshots highly space-efficient even for large environments.

Cloning Creates Independent Environments

Cloning creates new sandboxes from any snapshot in seconds. Each clone is fully independent with its own write layer, but clones don't duplicate underlying data.

This makes it practical to spin up dozens of identical environments for testing, parallel workloads, or agent swarms—without multiplying storage costs.

Safe Deletion with Dependency Tracking

Snapshots with active clones are never force-deleted. Akira tracks dependencies between snapshots and clones, with a background verification process confirming that deletion is safe before proceeding.

This prevents costly storage operations that could impact cluster performance or corrupt dependent sandboxes.

Automatic Deduplication

Similar environments across tenants benefit from significant deduplication at the block storage level, reducing overall storage costs without manual intervention.

If ten customers are running Python 3.11 with numpy, pandas, and matplotlib, they share the base layers. Only their unique changes consume additional storage.

Control Plane: Multi-Tenant Sandbox Management

The control plane orchestrates all sandbox operations, enforcing tenant-level isolation at every layer.

Sandbox Manager

Handles the complete sandbox lifecycle: create, execute commands, stream logs, upload and download files, and delete. Every operation is authenticated and scoped to the requesting tenant.

Snapshot Manager

Manages snapshots, clones, and restores with intelligent dependency tracking. The API provides a depends_on field so clients can see which clones reference which snapshots before attempting deletion.

Terminal Manager

Provides interactive PTY terminal sessions over WebSocket. Clients request a one-time connection ticket, then open a WebSocket for real-time terminal I/O with full ANSI/xterm support.

This enables interactive debugging and manual intervention when needed—without SSH, VPN, or bastion hosts.

All managers communicate with the underlying container orchestrator, which enforces namespace-level isolation between tenants for an additional security layer.

Sandbox Lifecycle: From Creation to Cleanup

Akira sandboxes move through well-defined states optimized for both speed and reliability.

CREATE: Provision a persistent block storage volume, boot a MicroVM, mount the layered filesystem (NVMe base plus block storage writes), and apply per-tenant network policies.

The entire provisioning process completes in under one second.

RUNNING: The sandbox accepts commands via REST API, SDK, or interactive terminal with full PTY support. Users have full root access inside the MicroVM, with all filesystem changes persisting automatically across restarts.

SNAPSHOT: Freeze the current sandbox state and capture an instant copy-on-write snapshot. The full root filesystem and all data are preserved.

Sandboxes can continue running immediately after the snapshot completes—no downtime, no service interruption.

RESTORE / CLONE: Create new sandboxes from any snapshot with optional resource reallocation (different CPU or memory allocations). New sandboxes are ready in seconds with the exact state captured in the snapshot.

DELETE: Stop the MicroVM and release the storage volume. If the sandbox has snapshots with active clones, those snapshots are retained safely until all dependencies are resolved through the automatic verification process.

Network-Based Observability for MicroVM Environments

Akira provides comprehensive observability across all sandboxes without requiring any agent installation inside the MicroVM—a critical advantage for security and operational simplicity.

Per-Sandbox Metrics

CPU utilization, memory usage, and lifecycle events are collected per sandbox and exposed through both the dashboard and API for programmatic monitoring.

Execution History

Every command executed through the API is logged with its output, providing a complete audit trail of sandbox activity for compliance and debugging.

Network Observation Layer

DNS queries, network flow logs, and policy violation events are captured at the network layer, providing visibility into all external communication from every sandbox.

Why Network Observability Matters for MicroVMs

Because each sandbox runs inside a MicroVM with its own guest kernel, traditional host-based syscall monitoring cannot observe workload activity without breaking the isolation boundary.

However, all meaningful security events—command and control communication, data exfiltration, lateral movement attempts—must traverse the network.

Network-based observability is therefore the architecturally correct security model for MicroVM platforms. It provides comprehensive threat visibility without compromising the isolation that makes MicroVMs secure.

All telemetry flows through a collection pipeline to an analytics backend, where it's queryable through the dashboard and API for security analysis, performance optimization, and cost allocation.

Access Layer: Multiple Interfaces, One API

Akira provides flexible access methods for different use cases, all backed by the same type-safe REST API.

Web Dashboard
Visual management interface for sandboxes, snapshots, and API keys, with an integrated terminal for interactive sessions.

REST API
Type-safe HTTP API supporting all platform operations: sandbox lifecycle, command execution, snapshot management, file operations, and metrics queries.

Native SDKs
Client libraries optimized for programmatic integration with AI agents and automated workflows.

Interactive Terminal
Full PTY terminal sessions over WebSocket with ANSI escape code support, window resizing, and interactive application compatibility. Accessible from the dashboard or programmatically via a ticket-based connection flow.

Dual Authentication Modes
- JWT-based session authentication for dashboard users
- API key authentication for programmatic and SDK access

All requests are resolved to a tenant namespace before reaching any sandbox operation, enforcing tenant-scoped access control at every layer of the stack.

Bare Metal Compute for Maximum Performance

Akira runs on bare metal nodes to eliminate nested virtualization overhead and maximize price-performance.

Hardware Virtualization
MicroVMs run directly on physical hardware with native access to CPU virtualization extensions, avoiding the performance penalty of nested virtualization.

ARM Architecture
Optimized for compute efficiency, providing more processing power per dollar than equivalent x86 instances while maintaining full compatibility with standard Linux workloads.

Efficient Multi-Tenant Packing
Multiple sandbox tiers with varying CPU and memory allocations are packed efficiently across the node fleet, maximizing infrastructure utilization without compromising isolation guarantees.

No Hypervisor Tax
By running on bare metal rather than cloud VMs, Akira eliminates the hypervisor overhead that adds latency and cost to cloud-based container platforms.

Security Model: Defense in Depth

Akira implements multiple layers of isolation to protect tenants from each other and the platform from malicious workloads.

Hardware Isolation

Hypervisor boundary per sandbox with separate guest kernels, protecting against kernel exploits and container escape vulnerabilities.

Network Isolation

Per-tenant network policies with full flow visibility, preventing lateral movement and unauthorized external communication.

Storage Isolation

Dedicated block volumes per sandbox with encryption at rest and in transit, ensuring data cannot leak between tenants.

Identity Isolation

Tenant-scoped authentication with JWT and API key support, ensuring requests are validated and authorized before reaching any infrastructure layer.

Unlike traditional container platforms that rely on namespace isolation with a shared kernel, Akira's hardware-level boundaries provide defense against entire classes of vulnerabilities that have historically enabled container escapes.

Why This Architecture

Akira's architecture is purpose-built for the unique requirements of AI agents, automated workflows, and untrusted code execution.

1. Security without performance tradeoffs: Hardware isolation with sub-second cold starts
2. Full filesystem persistence: Not just data volume but complete root filesystem state
3. Instant environment cloning: Spin up identical environments in seconds for testing and parallel execution
4. Network-based security visibility: Monitor all external communication without compromising isolation
5. Cost-efficient storage: Layered filesystem keeps base OS reads fast and free while persisting all changes.

For development teams building AI agents, running untrusted code or managing complex multi-tenant environments, Akira provides the security guarantees of dedicated VMs with the operational simplicity of containers and the performance characteristics of neither.