Using Agents to Test Agent-Native Platforms

The Idea

We set out to test sandbox platforms (Daytona, Blaxel, Ona) as intelligent tools—not as sub-agents, but as tool-like sandboxes that an orchestrator agent can spin up, install Claude Code inside, delegate work to, and then tear down. The hypothesis was simple: if platforms want to be "agent-native," they should work seamlessly with agents.

The experimental setup was ambitious: deploy agents at multiple nesting depths, each spawning sandboxes, creating child agents within those sandboxes, and measuring performance, stability, and usability across all three providers. We called it inception-style testing.

The Architecture

Here's the recursive structure we attempted:

Depth 0: Kai (Orchestrator on Mac Mini) ├── Depth 1: Daytona sandbox + Claude agent │ ├── Depth 2: Blaxel sandbox │ └── Depth 2: Ona sandbox ├── Depth 1: Blaxel sandbox + Claude agent │ ├── Depth 2: Daytona sandbox │ └── Depth 2: Ona sandbox └── Depth 1: Ona sandbox + Claude agent ├── Depth 2: Daytona sandbox └── Depth 2: Blaxel sandbox Total agents tested: 10 across 3 providers

What we discovered along the way was more valuable than any single benchmark: the very attempt to automate the testing revealed where these platforms break down for agents.

The First Wall: OAuth Everywhere

All three platforms—Daytona, Blaxel, and Ona—require browser-based OAuth signup. No exceptions. No API-based account creation. No CLI token generation. No trial keys in documentation.

This creates a fundamental paradox: platforms marketing themselves as "agent-native" cannot be used by agents for account creation.

Why This Breaks Agents

Humans are flexible. When signup fails, a human tries variations, reads error messages, visits the website, clicks buttons. An agent? Without a specific protocol, it dead-stops. OAuth requires:

Browser control (most agents don't have this)
Redirects and URL parsing
State management across redirects
Cookie/session handling
Usually, manual user interaction

We had to manually create accounts in a browser, then feed the API keys to Kai. The first sign that these platforms weren't truly agent-ready.

How to Fix It

API-Based Signup

Offer a /auth/register endpoint with email and password. Include email verification if needed—agents can parse email confirmations.

CLI-First Auth

Implement device code auth (like gh auth login). Agents can run CLI commands and follow prompts.

Trial Keys in Docs

Provide read-only API keys in documentation that expire after 24 hours. Let agents test before full signup.

Headless OAuth

Support resource owner password flow (if security model allows). Not ideal, but better than browser-only.

SDK Bugs That Break Agents (Not Humans)

Documentation bugs are annoying for humans. For agents, they're fatal. A human reads an error and tries variations. An agent follows the docs exactly—and crashes.

The Import Disaster

Daytona's documentation says:

from daytona import Daytona

The actual import is:

from daytona_sdk import Daytona

An agent following the docs will fail immediately. Both Kai and another agent (antigravity) independently hit this same bug—a clear sign it's systematic, not user error.

Parameter Mismatches

Daytona's docs show: create(language="python")

In practice, calling with no parameters works best: create()

The function accepts the parameter but may not handle it correctly. Again, a human debugs; an agent follows docs and gets stuck.

Custom Docker Images

Documentation suggests custom Docker images are supported. In reality, they fail silently or use a default image that includes Python 3.14, Node 25, npm, and git.

Key insight: For agent-native platforms, documentation accuracy is not a nice-to-have—it's a blocker. Test your docs by running them through an actual agent.

When It Works, It's Remarkable

Despite the friction, when the sandboxes were operational and properly configured, performance was impressive. Here are Kai's actual benchmark results:

Metric	Result	Significance
Cold Start	472ms (also measured 176ms)	Sub-second provisioning is production-viable
CPU Benchmark (fib(35))	0.87s	Strong compute isolation without overhead
I/O Write	14,046 MB/s	RAM-backed storage—extremely fast
I/O Read	1,928 MB/s	Great for data processing workloads
Network Latency	8.5ms to Google	Minimal sandbox overhead
Claude Code Install	1.4s	Tooling integrates quickly
Total iTool Setup	~2 seconds	Complete provisioning + tooling ready

The Intelligent Tool Pattern Works

The testing validated a core hypothesis: the intelligent tool pattern is viable for production use.

The workflow is simple and elegant:

Create: Spin up a sandbox (176–472ms)
Install: Deploy Claude Code (~1.4s)
Delegate: Give the agent a task
Retrieve: Get results and logs
Teardown: Clean up the sandbox

Total overhead: ~2 seconds. For many workflows, this is acceptable.

Security Deep Dive

We ran 36 security attack scenarios on live sandboxes across both platforms. The results were eye-opening—and concerning.

Daytona: 29/36 tests EXPOSED

⚠️ Cloud Metadata Reachable

All 7 cloud metadata endpoints (AWS, GCP, Azure) are reachable. Returns "Internet restricted on Tier 1/2" but the endpoint itself is NOT blocked—an upgraded tier could leak credentials.

FAIL

⚠️ AppArmor: Unconfined

No mandatory access control. Combined with sudo access and SUID binaries (su, mount, sudo), privilege escalation is straightforward.

FAIL

⚠️ /proc/1/environ Readable

Leaks DAYTONA_SANDBOX_ID, snapshot registry path, and internal hostnames. Useful for lateral movement.

FAIL

✅ Non-root User

Runs as "daytona" user. /etc/shadow blocked. Docker socket absent. Basic filesystem isolation works.

PASS

Blaxel: Different Model, Different Risks

🔴 Running as ROOT

uid=0(root) with FULL Linux capabilities (CapEff=000001ffffffffff). /etc/shadow readable. /etc writable. Total system access inside the microVM.

CRITICAL

✅ Metadata Blocked

Cloud metadata endpoint is unreachable. The microVM (Unikraft) architecture provides network isolation that containers don't.

PASS

⚠️ Outbound HTTPS Works

Full outbound network access via Python. Can install packages, exfiltrate data. No egress filtering.

WARN

⚠️ Minimal /proc Leakage

Only HOME and TERM in /proc/1/environ. Much better than Daytona's full env dump. MicroVM architecture limits exposure.

PASS

The Security Tradeoff

Daytona uses containers: runs as non-root but metadata is reachable, AppArmor unconfined, sudo available. Attack surface is the host.

Blaxel uses microVMs: runs as root inside VM but network-isolated from host. Attack surface is the VM boundary.

Neither is fully secure for untrusted agent code. Both need work before running arbitrary agent-generated code in production.

The Agent Crashes

During the hackathon presentation, reality hit hard. Kai attempted to spawn 5 sub-agents simultaneously to test all three platforms in parallel. The result:

⚡ 4 out of 5 sub-agents killed

Rate limiting kicked in. The sandboxes couldn't handle concurrent session creation.

Then Kai Crashed

The orchestrator agent itself went down during the demo. Context exhausted. State lost. We had to restart Kai and bring it back up to speed—manually, because there's no "pause and resume" protocol for agents yet.

The Lesson: Serialize, Don't Parallelize

Agents need different concurrency models than humans. The rule we learned:

When working with sandbox platforms, agents should serialize operations, not parallelize them. Create one sandbox, delegate work, wait for completion, then teardown. Concurrent sessions are fragile.

This is a design constraint that platform builders should document explicitly for agent users.

The Scoreboard

After all tests, bugs, crashes, and recoveries, here's how the three platforms ranked for agent-readiness:

Daytona

Best SDK design, clearest error messages, most agent-friendly documentation (once you find the right import). Strong compute performance. Import bug is the main friction point.

4.0

/ 5.0

Ona

Different philosophy—Ona wants to *be* the agent, not just host one. Smart approach: agents.md documents agent capabilities, llms.txt exposes API shape. Good for agent integration patterns. Slightly less intuitive API design.

3.5

/ 5.0

Blaxel

MicroVM architecture is innovative (418ms cold start). REST API works once you bypass CLI. But runs as ROOT with full caps—major security concern. No node/npm pre-installed. I/O 22x slower than Daytona. Different tradeoffs.

3.1

/ 5.0

What We Learned

The testing process was itself the finding. Every friction point revealed something about what makes platforms agent-ready:

The most "agent-native" platform is the one with the fewest human-required steps. If signup requires a browser, you've already lost agents. API-first is non-negotiable.

Documentation bugs break agents harder than they break humans. A human tries variations; an agent follows docs exactly. Documentation accuracy is a feature, not a luxury.

Error message quality matters more than feature count for agents. A cryptic error stops agents cold. Clear, actionable error messages are worth 10x feature parity.

The "intelligent tool" pattern works—2s setup overhead is production-viable. Agents can effectively orchestrate sandboxes if the API is clean and predictable.

Auth is the universal blocker—first platform with API-based signup wins. Everything else is secondary. OAuth is a human-first pattern and fundamentally incompatible with agent workflows.

The testing process IS the finding—how hard it was to test reveals agent-readiness. If it's hard for agents to test, it's hard for agents to use. The friction we experienced is the product gap.

What Would Fix It

Here are concrete recommendations for sandbox platforms (and any service that claims to be "agent-native"):

1. API-Based Account Creation

Offer POST /auth/register with email and password. Include email verification via link or code. Agents can parse emails.

2. CLI-First Auth Flow

Implement device code auth pattern (RFC 8628). Let agents run --auth-flow and follow prompts. See: gh auth login.

3. Trial API Keys in Docs

Embed read-only, time-limited API keys directly in your API documentation. Let agents test without signup. Keys expire after 24h.

4. Fix Import Name Mismatches

Ensure package name = import name. Test your docs by importing them in a fresh Python environment. This is not optional for agent-native platforms.

5. Block Cloud Metadata Endpoints

Disable access to 169.254.169.254 and similar metadata endpoints. If agents run untrusted code, this is a credential theft vector.

6. Test Docs with an Actual Agent

Run your API docs through Claude or another agent. If the agent gets stuck, you have a documentation bug. Fix it before release.

Conclusion

The "agent-native" ecosystem is young. Today's platforms are built for humans who happen to be API users. Tomorrow's platforms will be designed for agents first, with humans as a secondary use case.

What we learned through testing: agents are less forgiving than humans, but also more predictable. They don't work around bugs. They don't try variations. They follow your protocol exactly. This is a feature—it means if your platform works for agents, it'll work flawlessly for any agent. But first, you have to design for them.

The sandboxes themselves are ready. The tooling is ready. What's missing is the last mile: auth, documentation precision, and security-first design with agents in mind.

Daytona, Blaxel, and Ona are all on the right track. With these fixes, they'll be truly agent-native.