Default guardrails
Safe-mode behavior should be the starting posture, not an optional afterthought.
safe defaults · explicit trust · visible boundaries
Phase1 Security Model
Phase1 treats security as part of the operator interface. The goal is to make safe mode, host trust, browser boundaries, and audit visibility clear instead of hidden.
model summary
Security should be visible to the operator.
Phase1 is designed as a Rust virtual OS console with safety information exposed through the shell and docs. The model is simple: default to guarded behavior, require explicit trust for host-backed workflows, and describe limitations clearly.
Explicit trust
Host-backed tools should be intentional and visible to the operator.
No inflated claims
Docs should separate implemented features, planned features, and security aspirations.
safe mode
Safe mode is the expected starting state.
Safe mode keeps Phase1 focused on contained learning and inspection workflows. It is meant to reduce surprise by avoiding silent host execution and keeping powerful behaviors behind clearer operator choices.
Use this command family to inspect current safety posture and guidance.
Audit views are intended to show visible records of important events where supported.
Use the local build help output to see which safety-related commands are available.
host trust
Host-backed workflows must feel intentional.
Some planned workflows, such as storage, Git, Rust builds, and host-tool execution, may require access outside the virtual shell. These paths should be visibly guarded and should not require disabling all security to test a feature.
- Host-backed tools should be labeled clearly.
- Trust decisions should be explicit and reversible where practical.
- Capability metadata should explain what a command can do.
- Testing workflows should be guarded, not blocked by vague behavior.
browser boundary
The guarded browser should not behave like a hidden web runtime.
Phase1 browser workflows are meant to be terminal-first and inspectable. The docs should make clear which schemes are allowed, whether active content is stripped, how loopback fallbacks behave, and what network data is exposed.
Scheme restrictions
Document supported URL schemes and blocked behavior plainly.
Active content
Scripts and dynamic content should not silently run in unsafe ways.
Operator visibility
Network output should be visible, searchable, and easy to inspect.
secrets policy
Normal Phase1 use should not require secrets.
Visitors should not need to paste passwords, private keys, tokens, or personal credentials into Phase1 for ordinary use. If a future workflow needs credentials, the docs should describe that boundary explicitly before the feature is presented as ready.
- Do not ask users for private keys or account passwords for normal workflows.
- Keep token-based integrations out of the default quick start.
- Document any credential requirement before the command is promoted.
- Prefer local, inspectable, no-secret workflows for demos and tutorials.
audit + visibility
Safety depends on being able to see what happened.
Audit logs, process views, generated system paths, and status indicators help users understand what the virtual console is doing. These are usability features and safety features at the same time.
Inspect simulated process table state where available.
Explore generated system views in the virtual filesystem.
Review public roadmap and project status boundaries.
Separate implemented behavior from planned behavior.
operator checklist
Before using a powerful workflow, ask five questions.
- Is safe mode on? Start from the guarded posture.
- Does this command touch the host? Identify host-backed behavior before running it.
- Does this require a secret? Avoid passwords, private keys, or tokens unless a future doc explicitly explains the boundary.
- Can I inspect the result? Prefer workflows that expose logs, status, or files.
- Is this implemented or planned? Check the wiki, command reference, and status page.
non-claims
What this page does not claim.
This page describes the intended Phase1 safety model and documentation boundaries. It does not claim Phase1 is production-ready, installer-ready, daily-driver ready, hardware-validated, security-hardened, cryptographically complete, or a complete operating system.