Arcane OS Docs Development only

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.

  • Assurance

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.

Repository and reviewed source access