Security & control
Autonomy without control is just another problem.
The point of an assistant that acts is not that you trust it blindly. It's that you can see what it's doing, stop what you don't want, and verify what happened. These are the rules the whole system is built around.
Local data when possible
Astro stores your notes in SQLite on your machine. The default is local; the cloud is an option you choose, not a requirement you accept.
Your API keys, for now
In the first versions, external models run on keys you provide and can revoke. Later you'll also be able to lean on Solen's own services and keys (Anthropic, OpenAI, and the rest through us) or on local models. Your call, always.
Permission modes, like a real tool
Four modes: Manual (you approve everything), Plan (it proposes, you decide), Auto (it works and asks only when something matters), and Always-approve (it never asks; you accepted that). You pick the leash length.
Sandboxed execution, if you want it
Code can run in isolated containers with limits on filesystem, network, and processes. It's an option, not a cage: you decide when the sandbox is on and when Jarvis works directly on your machine.
Readable logs: the hard goal
Every run should leave a plain-language trace of what was attempted and what happened. Honestly: this is hard to do well, especially for cloud runs. It's a goal we're building toward, not a solved problem.
Fully local mode where supported
With Ollama, parts of the system can run entirely on your hardware. Slower, sometimes. Yours, always.
Tools you can switch off
Don't want the agent touching the browser, or the terminal, or anything at all? Disable specific tools and it works within what's left.
The architectural rule
The model never executes dangerous actions directly. It proposes an action; an authorized runtime decides if and how to run it.
This is why Jarvis can be ambitious about capability without being reckless about control. See it in practice on the Jarvis page.