Purvakalpa Studio

Docs / Tasker

Security

Two layers of protection for synced data, where every key lives, what an assistant's key can and cannot do, and the threat model in plain language.

Layer 1: your iCloud private database

With sync on, Tasker stores data in SwiftData backed by the CloudKit private database of your own Apple ID.

  • The data lives in your iCloud, not on a server we run. We have no backend and no way to read it.
  • CloudKit encrypts data in transit and at rest, and access is tied to your Apple ID.
  • Sync is off by default; the app runs fully local until you turn it on.

Layer 2: end-to-end encrypted notes and pages

Notes and page bodies hold the most sensitive writing, so they get a second layer:

  • TaskCrypto seals the text with AES-GCM (256-bit) through CryptoKit before it is written to the store. A sealed value is stored as a short marker followed by base64 of the nonce, ciphertext and tag.
  • The key is generated on the device and kept in the Keychain as a synchronisable item, so it travels to your other devices through iCloud Keychain, which Apple encrypts end to end. The key never goes through Tasker’s CloudKit records.
  • Even inside your own CloudKit database, note and page contents are ciphertext. Only a device holding the key can read them.
  • Decryption happens when the text is shown. Values without the marker pass through unchanged, so older plain notes still open and turning encryption on is safe.
DataLayer 1 (CloudKit)Layer 2 (app encryption)
Note text, page bodiesEncryptedAES-GCM with your key, on by default
Titles, dates, status and other fieldsEncryptedNo; protected by CloudKit and your account
Attachment bytesStored as files, on the device or in your own iCloud DriveOptional, off by default

Keys that never roam

  • Your own AI keys (OpenAI-style providers) are stored in the device Keychain and are not synced. They never touch CloudKit.
  • Assistant keys are minted as tk_ plus 256 random bits, shown once, and stored only as a SHA-256 digest. Revoking is one write. Keys are excluded from backups, so a restored assistant starts without one. See Agent platform.

Fail closed

  • An unknown or revoked key makes task-mcp exit with an error. It never falls back to trusted mode.
  • The HTTP binding requires a key; trusted mode never leaves stdio.
  • If an assistant’s request cannot be decided, the gate asks or refuses. It does not guess.

Threat model

  • Someone gets into iCloud or intercepts sync: note and page contents are ciphertext, and everything is already account-scoped and encrypted by CloudKit.
  • The developer: no backend, no keys, no access, even in principle.
  • A lost device: the Keychain key is protected by the device passcode and is only readable after the device has been unlocked once since it started. Restoring iCloud Keychain needs your Apple ID and a trusted device or recovery.
  • A misbehaving assistant: it can only do what its trust level and capability grants allow, inside its budgets and outside quiet hours. Risky actions wait for your approval, every action leaves a receipt, and additions and completions can be undone from it.

What a model can see

Planning providers never see your tasks directly. They receive a PlanContext: for each candidate task, only the title, estimate, due date, priority, energy and an overdue flag. Notes, contexts, attachments and any other free text never enter it, so they cannot reach a cloud model by construction. The assistant’s free-form questions use the same kind of minimised task context.

No telemetry

The engine makes no network calls of its own and there are no analytics. Data leaves the device only through options you turn on: iCloud sync, a paired device on your Wi-Fi, a local AI server on your network, or a cloud AI provider with your own key.