Local data and privacy

AI OS keeps the local operator boundary separate from its public surfaces.

Local inputs

Depending on setup and installed tools, the local host can inspect bounded signals such as tool readiness, saved skills, memory sources, workspaces, session summaries, usage metadata, scheduler state, and extension output.

The browser receives validated projections designed for a product surface. It must not receive private account material, full machine paths, detailed local diagnostics, provider response bodies, or unreviewed generated files.

Local actions

Routes that can refresh data, run Dream, invoke an agent, or write local state remain local. Their implementation uses the controls appropriate to the route, including loopback and host checks, same-run tokens, schema validation, timeouts, safe errors, redaction, argument-only process launch, and confined paths.

These are local product routes, not a hosted public API.

Provider processing

Some explicitly configured local workflows can send selected request material to a third-party provider. The subscription-backed OpenAI runtime is one such script-only path for Dream and Trend Finder. Authentication stays local, but the request leaves the machine and remains subject to provider processing, entitlement, quota, and retention behavior.

Hermes, Voice, source collectors, and the subscription runtime have separate readiness and data contracts. Enabling one does not silently enable another.

Public surfaces

• The product site is static marketing content.
• The demo is a static reviewed snapshot.
• This documentation site publishes only curated pages from its own content directory.

None of these surfaces imports the repository’s internal maintenance tree or generated local data.

Use Configuration boundaries before adding local runtime settings, and OpenAI subscription runtime before enabling account-backed analysis.