Isolated Environments for Every Agent Run
Each run gets its own clean environment with only the access it needs, not a developer's machine next to their files and credentials.
A Separate Environment for Every Session
Each session gets its own agent workspace, created from a versioned snapshot. A different session gets a different workspace.
checkout-api session
- RepositoryRead and write
- CI logsRead
- Developer laptops
- Production keys
Platform Credentials Stay Out
The workspace that runs commands is separate from the agent that coordinates the work. Model keys and platform credentials are filtered out of the workspace.
Coordinator keeps
- Model keys
- Platform keys
Keys filtered out
Workspace receives
- Repo clone
- Task env values
Access You Choose
Give an agent only the repositories, integrations, and environment values the work needs. Named environments keep staging and test credentials apart.
- DATABASE_URLpostgres://••••
- STRIPE_KEYsk_test_••••
Common Questions
Is it safe to let agents run unattended?
Each run happens in its own isolated environment with limited access, not on a developer's machine. Every session is visible to the team, and results come back for a person to review.
What can an agent's workspace access?
The repositories, integrations, and environment values you provide for the work. Outbound network access is open by default, and Felan's platform credentials, such as model keys, are filtered out.
Do sessions share a workspace?
No. Each session gets its own workspace. Specialized agents working inside one session share that session's workspace so they can work on the same files.
Does isolation replace least-privilege access?
No. Use scoped test accounts, narrowly scoped provider permissions, and non-production data where you can.
Learn more: Security docs, Self-hosting.
Keep Your Attention for the Hard Problems
Start with one repo and one recurring task.