Permissions are tied to understandable jobs
File access, accessibility control, microphone use, notifications, and other system capabilities should be requested when their related feature needs them. A denied permission should produce a clear recovery path instead of a silent failure.
Basic typing or browsing should not inherit a broader permission merely because another feature can use it.
Under the hoodHow it works
- File access, Accessibility, microphone, notifications, camera, and keyboard Full Access are separate system capabilities.
- Denial must identify the missing capability and offer a scoped recovery path without broadening another permission.
Credentials are protected separately from ordinary settings
Tokens and provider credentials are encrypted at rest. They must not be printed in logs, copied into diagnostics, stored in source files, or treated as ordinary synchronized preferences.
A portable credential design also avoids relying on a platform-only storage decision that would block future clients.
Under the hoodHow it works
- Axiom encrypts stored credentials with AES-256-GCM and keeps keys and tokens out of logs and source files.
- Credential records remain separate from ordinary preferences and synchronized project content.
Desktop actions prefer known elements over guessed coordinates
When macOS accessibility information identifies a control, Axiom should act on that element rather than a predicted point. Coordinates are a last resort. If a point is outside the valid range, the system refuses it instead of clamping it into a plausible but wrong click.
Foreground effects belong to the user’s task. Attachment inspection and other internal preparation should remain invisible unless a visible action is necessary or requested.
Under the hoodHow it works
- The action ladder prefers semantic element references, then validated geometry, with coordinates as a last resort.
- Internal attachment preparation stays in the background unless the requested outcome needs a visible application.
Every connection has its own boundary
Hosted AI providers, synchronization, public sharing, update services, and media providers are not one generic cloud. Each connection has a different purpose and should receive only the data needed for that purpose.
Provider policies and capabilities can change. Current provider-specific claims should be verified at the time they matter rather than frozen into a permanent privacy slogan.
Under the hoodHow it works
- Model inference, encrypted sync, public publishing, media providers, and updates have independent endpoints and data contracts.
- The selected provider controls its own retention, availability, and policy outside Axiom’s local boundary.
A green build is not live evidence
Axiom distinguishes source tests, compiled artifacts, signed applications, host acceptance, virtual-machine acceptance, live deployment, and physical-device testing. Passing one gate does not silently promote the others.
The changelog and release notes should continue to name what was observed and what remains untested. That honesty is part of the product’s security model because users can separate intended behavior from proven behavior.
Under the hoodHow it works
- Source tests, compiled artifacts, signed builds, installed-app acceptance, clean-machine checks, deployment, and physical-device use are separate evidence levels.
- Every claim should identify the artifact, environment, action observed, and untested boundary.
Sources and scope
We wrote this from Axiom's current code, regression tests, and recorded product checks. If a behavior has only passed a source test, we do not describe it as proven on every Mac. There are no invented benchmark numbers here.