Arcane OS security model

Arcane OS is in active development. This page describes the security behavior that users and reviewers can rely on today, the limits of that behavior, and the work still required before a release claim. It is not a security approval, penetration-test report, or guarantee that the system is free of defects.

This public model intentionally describes security properties and residual risk without publishing defensive layout details, private identifiers, exact service locations, or step-by-step abuse paths. Those details do not make the public claims stronger and can turn an honest disclosure into an attack recipe.

Warn-first verification boundary

Arcane defaults to warn first for recoverable verification differences. A hash, checksum, or byte mismatch should remain visible without taking down the operating-system interface or its recovery path. Users can opt into fail-first behavior when they want an operation to stop on the first recoverable warning.

Warn-first does not mean trust-first. Bytes that Arcane cannot trust are not executed, activated, restored as trusted state, or granted capability or privilege. The system can continue serving unaffected functions while the affected operation reports a warning and remains unavailable.

Identity, authorization, capability, privilege, safe-path, transaction, and rollback failures are not downgraded to warnings. They still stop the affected operation because continuing would widen authority or make recovery uncertain.

What hashes can and cannot prove

A matching hash proves only that observed bytes match an expected value. It proves authenticity only when that expected value is protected by an independent authority that cannot also replace the artifact.

A hash stored beside a file, generated from the same file, or replaceable by the same authority as the file is useful consistency evidence. It can detect accidental damage or an incomplete transfer, but an attacker who can replace both values can make them agree. Arcane therefore does not use such a hash alone to authorize execution, activation, privilege, rollback, or a trusted label. A separately authenticated publisher binding is a different trust fact.

Publisher identity and other independent trust anchors remain separate from consistency checks. Repeating the same hash over unchanged bytes does not add a new security fact.

What Arcane protects

The current security design focuses on:

• user identity, consent, account state, and the ability to recover;
• application identity, declared capabilities, and separation between apps;
• privileged operations and the exact request the user authorized;
• application packages, system components, publisher continuity, and updates;
• user files, preferences, conversations, credentials, and provider-bound data;
• local and remote service boundaries, including AI and communications;
• availability of the interface, maintenance path, and recovery tools; and
• diagnostics and audit evidence that must not become a second copy of private content or secrets.

Main trust boundaries

Applications and Arcane Core

Applications are treated as untrusted callers of a narrow platform API. Arcane Core checks the bound application identity, capability policy, request shape, and result contract. An application cannot grant itself a capability merely by requesting a method or editing renderer content.

The platform supplies reusable capabilities, including app-neutral speech status, synthesis, and transcription. Whether an app adopts a speech-first experience is an app-design choice, not an operating-system policy or special trust grant.

Privileged work

Privileged work is expected to be short-lived, narrowly scoped, and bound to the approved operation. A warning must never become permission to continue with an unknown caller, changed parameters, unsafe location, or unverified authority.

Packages, installation, and recovery

Candidate packages are checked before activation, and an affected candidate is not used when its independent trust evidence fails. Install and repair flows should keep a usable interface and known-good system available whenever that is safe. Recovery must not turn newly measured, untrusted bytes into a trusted baseline merely because a fresh hash was written for them.

User data and providers

Arcane aims to minimize the data collected, retained, logged, exported, and sent to providers. Local processing reduces some exposure but is not itself an authorization or confidentiality guarantee. Remote transmission, microphone use, protected-value reveal, and other sensitive actions still require the applicable capability and user-facing context.

Local services and external systems

Local services, repositories, package sources, identity providers, signing systems, and remote APIs remain separate trust boundaries. A compromised or unavailable dependency can disclose data, return hostile content, impersonate an expected peer, or deny service. Arcane validates and limits these crossings, but development evidence does not prove the external system is trustworthy.

Current residual risk

Arcane does not yet claim production signing, a public installer, a supported update channel, complete clean-machine acceptance, complete accessibility acceptance, independent security approval, or release-candidate status.

Credible remaining risks include compromised administrator or publisher authority, malicious application or model content, dependency compromise, local peer impersonation, provider data handling, resource exhaustion, interrupted updates, incomplete rollback, inaccessible recovery, and mistakes in authorization or isolation code. Some development platforms also lack an independent publisher-authenticity boundary and must remain clearly labeled as development-only.

These limitations are reasons to keep testing and hardening; they are not instructions for bypassing a control. Exact operational findings are tracked in the controlled engineering review process and are disclosed publicly at the level needed to understand impact, affected boundary, remediation, and current status.

Disclosure standard

Public security documentation should answer four questions:

1. What security property does Arcane claim?
2. What does it deliberately not claim?
3. What happens when the boundary fails?
4. What residual risk or promotion work remains?

It should not publish private identifiers, exact defensive locations, secrets, credentials, live endpoints, internal tracker links, or a reproducible bypass sequence. A future vulnerability notice should describe impact, affected versions, mitigation, and fixed versions without exposing more operational detail than users need to protect themselves.

Continue with the Security and privacy review for the review principles used during development and future promotion work.