On October 23, Daytona raised a $60M Series B at a $1B valuation (FirstMark led; total raised is now $91M, with angels including Stripe's Patrick Collison, Shopify's Tobi Lütke, Perplexity's Aravind Srinivas, and Zoom's Eric Yuan). Daytona's product is not a smarter agent. It's a place for agents to run: their argument is that agents don't run like traditional services, so every agent should get its own sandboxed computer — Linux, Windows, macOS, GPU.
The same day, Berlin-based Cygrid came out of stealth with a €2.66M pre-seed to build the opposite half of the same idea: a unified identity graph for humans and AI, with real-time limits on which sensitive data an agent may touch. (A third company, Modelyo, raised $17M the same day for confidential cloud.) One day, three checks, all written for the same thesis: the market has stopped asking only "how capable is the agent?" and started asking "what is it allowed to break?"
If you run agents as a solo operator or a tiny team — scheduled automations, an agent that answers mail, posts content, ships orders — you are not going to buy a sandbox cloud or an identity graph. But here's the thing I keep coming back to: most of what those products sell is not exotic technology. It's separations. And separations can be written down as a checklist and enforced by habit. Below is the checklist I actually run for my own one-person operation, with the real setup included where it matters.
Why an agent needs walls at all
A script fails where you point it. An agent fails creatively — it reads files, follows instructions embedded in web pages and emails, calls APIs, sends messages, and can spend money, at machine speed, while you're asleep. The risk isn't mainly that it goes rogue; it's that an ordinary mistake — a misread rule, a poisoned input, a loop — has your full access behind it. Isolation doesn't make the agent smarter. It makes the blast radius smaller. That's the entire game.
The checklist
1. A separate environment per agent
Each agent (or each job) gets its own environment: its own browser profile, its own working directory, its own account where the tool allows. The folder contains only what the job needs, and originals live outside it — the agent works on copies, so a trashed environment is an inconvenience, not a loss. One job per environment: the agent that delivers my store's orders does not also hold the keys to everything else.
2. Separate keys, least privilege
One credential per agent, per purpose — never my personal login, never a shared admin key. Two agents using the same service get two keys, so one can be revoked without touching the other. Permissions are scoped to the job: the delivery agent can read one orders mailbox and send one delivery template from it. Nothing else. Keys live in a dedicated secrets file with owner-only permissions ('0600'), never in prompts, chats, or project files. If a key ever appears somewhere it shouldn't, it's rotated on suspicion, not on schedule.
3. Hard caps on money
This is the one people skip, and it's the one that converts a bad night into a bad story instead of a bad month. My store's payouts land in a dedicated operating wallet — petty cash, not a treasury. The rules, written down before the first dollar arrived:
- Balance cap: $200. Anything above it gets swept back to the owner's main wallet. The agent-facing wallet can never accumulate more than that.
- Custody off. The payment processor's custody is disabled, so payouts settle directly to our own address instead of piling up on a platform.
- Two jobs only: receive small income, pay small pre-agreed operating costs. No trading, no staking, no lending.
- The private key stands alone — in its own permission-locked file, generated without ever being printed, verified by deriving the public address from it.
The same principle applies to APIs: every paid key the agent uses has a spend limit or alert sized so a runaway loop is annoying, not damaging.
4. Reversible by default, logged always
Every external action my agents take lands in an append-only log, and the agent re-reads that log before acting — the log is also the dedupe mechanism, so nothing ships twice. New automations run report-only first: my delivery system spent a week showing me what it would send before it sent anything. Drafts over sends, copies over moves, trash over permanent delete. Anything irreversible gets a human checkpoint or doesn't get automated. Even the rules documents are versioned, so a bad edit to an agent's instructions rolls back like code.
5. A kill switch you've actually pulled
Before an agent goes live, the stop procedure is written down, in order: disable the schedule, revoke its keys, pause its payouts. Three moves, under a minute. Every agent's standing instructions carry the same hard rule — anything the written rules don't cover means stop and report, never improvise. And I test the switch while nothing is wrong, because a kill switch you've never used is a hope, not a switch.
Honest limits
A checklist is discipline, not a hypervisor. It will not match a real sandbox if you're executing untrusted code, and it depends on the operator actually keeping the separations — no tool enforces that for you at this scale. What it does cover: the realistic failure set for a small operation running scheduled, business-task agents: the misread rule, the duplicated send, the leaked key, the loop that spends. For those, small, capped, logged, and stoppable beats powerful and wide-open — at roughly zero dollars, which is the correct price for most of us.
This checklist is the newest module of my Solo Operator Agent OS — the full set (auto-delivery rules, money radar, open-source scouting, content pipeline, and this) is at TobyWater Digital, where the auto-delivery module is published free in full, exactly as it runs my store.