Security model

Local-first describes where Aleph’s working state lives. It does not, by itself, prove that an operation is safe. The security model is organized around specific boundaries and least-privilege access.

Boundary	Intended control
Guest ↔ host	Python and shell execution are isolated in a guest on macOS; if the guest is unavailable, execution must fail closed rather than silently run on the host.
Workspace ↔ filesystem	File capabilities are scoped to authorized workspaces. Path and symlink handling must preserve that boundary.
Browser ↔ network	Browser control is a separate capability. Destination policy must account for name resolution and redirects, including private and loopback destinations where access is not authorized.
Connector ↔ external account	OAuth uses a local callback boundary with state, nonce and PKCE validation. The provider remains an external trust boundary.
Generated artifact ↔ application	Untrusted previews and generated content must not inherit native application authority.

These are architectural controls and release-validation criteria, not a claim that every check has passed in an unpublished build. Specific internal paths, bypass histories and implementation secrets are intentionally omitted from this public description.

Credentials are not one flow

Bring-your-own API keys configure direct model or provider access. OAuth authorizes an external account through a provider-managed flow. They have different lifecycles and scopes. A connector should receive only the authority needed for its operation; a remote call also subjects the data sent to the external service’s terms and controls.

Release gates

Packaged builds need clean-profile startup, code-sign verification, workspace smoke tests, guest execution checks, browser and filesystem boundary checks, packaged OAuth tests, artifact-rendering checks, and secrets/personal-data sanitization. The distribution page separates these validation requirements from published release status.