Assurance
Arcane OS security model
Public security guarantees, limitations, warn-first verification, residual risk, and why same-authority hashes are consistency evidence rather than authentication.
Arcane OS is in active development. Ordinary operation prioritizes complete functionality and complete content. Optional hardening is not an ordinary runtime or development gate and is not enabled merely because a mechanism or setting exists.
Complete ordinary behavior
Arcane applications must return, render, search, log, and pass through the complete requested content. They must not shorten content, discard earlier results, replace full text with summaries, or use content measurements or identities as product requirements. When one shared provider operation cannot carry the result, its owner must use ordered continuation or streaming and report the external limit honestly; an app must not silently claim completeness.
If an external protocol requires framing information, that information stays at the protocol boundary and does not become an application result limit or a general development policy.
Controls that remain at their exact owners
Arcane continues to respect controls that are not optional product hardening:
- operating-system permissions and privilege prompts for machine-changing work;
- protection of passwords, API tokens, signing material, and other credentials;
- the user's explicit privacy and provider choices;
- rejection of malformed selected input that cannot be processed honestly;
- applicable legal and platform requirements; and
- an explicit user prohibition for the current operation.
These boundaries do not authorize unrelated isolation, admission, provenance, integrity, signing, freezing, restrictive validation, or fail-closed machinery.
Optional secure mode
secure is a plain boolean whose default is false. Any optional secure mode
requires an exact user instruction for the affected operation and an explicit
secure: true selection. Without that selection, ordinary behavior remains
available and complete. A dormant setting, future plan, release note, or
existing code seam is not authorization to activate or enforce optional
hardening.
Credentials and remote providers
Arcane does not place credentials in public documentation, source examples, screenshots, logs, or assistant context. When an application can send content to a remote provider, it identifies that provider and preserves the user's local or remote choice. This credential and privacy handling belongs to the exact provider boundary; it does not justify shortening the content the user asked the application to process.