Companion app security
What you'll find here
The security posture for companion surfaces — desktop, mobile, voice, multimodal. Companion surfaces are governed operator surfaces. They expose status, review notifications, and explicit operator-triggered actions, but must never become unreviewed background automation channels.
Companion surfaces don't store secrets.
If a companion action needs authority, it references an existing policy envelope, capability grant, or approval record — never cached credentials.
Read alongside
Credential handling
Companion records may preserve
- Policy envelope ids
- Capability grant ids
- Approval receipt ids
- Evidence ids
- Task ids
- Sanitized summaries
Companion records must NOT preserve
- Raw tokens · passwords · API keys
- Private payloads
- Unredacted prompts
- Credential-bearing URLs
Local storage
Desktop and mobile companion state must be encrypted when persisted. Stored records must be minimal and reconstructable from durable Craik records.
Allowed companion state
- User-visible notification ids
- Last-viewed task ids
- Display preferences
- Redacted artifact references
- Receipt ids for recorded actions
Prohibited companion state
- Secrets or credentials
- Raw multimodal payloads
- Private local workspace paths
- Unredacted transcripts
- Generated speech payloads
- Raw canvas state exposing private content
Notifications
Companion notifications require operator controls — operators must be able to disable, filter, or defer notifications. Notifications link back to reviewable Craik records instead of embedding private content.
Approvals and actions
Operator intent is required.
Companion-triggered actions require explicit operator intent. Background actions are disabled unless a later product surface defines a reviewable action queue with policy and receipt guarantees.
Every companion-triggered action preserves:
Actor identity
Policy envelope id
Evidence ids
Receipt id
Action summary
Result status
Mobile offline action queues are deferred unless they can guarantee receipts, ordering, replay protection, and operator review before side effects occur.
Future craik:// URL handlers must route only to review pages such as
status, dashboard, or approval detail views. A URL handler must never
auto-approve, auto-deny, submit credentials, or dispatch a mutating
runtime action from a deep link alone.
Redaction boundary
Companion surfaces use the same redaction posture as other Craik runtime records — preserve ids and summaries, not raw payloads.
Redact: secrets and credentials · local-only paths · private prompts · raw transcripts · raw audio, image, video, or generated speech payloads · raw canvas state · private notification payloads.
Validation
uv run --extra dev pytest tests/test_desktop_companion.py tests/test_mobile_companion.py
uv run --extra dev pytest tests/test_voice_posture.py tests/test_multimodal_artifacts.py
uv run --extra dev pytest tests/test_accessibility.py tests/test_docs.py
Expected: passed.
For the desktop companion MVP, also validate the CLI wrappers:
craik desktop status
craik desktop menu
craik desktop action open_dashboard
craik desktop notify-approval approval_123 model.chat "provider request"
The output must remain redacted, local-vs-remote posture must be explicit, and gateway start/stop/restart actions must require confirmation rather than running silently in the background.