A field note for the person who remembers everything

To the person behind the calendar,

Private task management for executive assistants.

The work is rarely just scheduling. It is the reason a meeting moved, the name behind a delicate follow-up, the draft that cannot circulate yet, and the promise an executive made in a hallway.

Keep the operational thread in an encrypted task layer. Keep credentials, source documents, board materials, and formal records in the systems built to hold them.

Last reviewed

Short answer.

SealTask can provide a private coordination layer for executive assistants when it holds only the next action, owner, and approved context. Keep calendars, board materials, credentials, identity documents, and formal records in their specialist systems. Task content is encrypted before sync, while timing, status, membership, and other operational metadata remain server-visible.

The calendar records when. It does not record why.

Email, calendars, travel tools, and board portals each own part of the work. The missing layer is a private place to coordinate the handoffs between them.

Context accumulates around ordinary reminders.

A short task can reveal a negotiation, health issue, personnel concern, investor conversation, or unreleased decision even when no document is attached.

A shared executive inbox is not a least-privilege task system.

Delegation works best when a collaborator receives the exact project needed for a handoff, rather than permanent access to every private thread.

General task vendors can usually process readable content.

Encryption at rest protects storage media. It does not, by itself, stop the service from reading task titles, indexing them on a server, or processing them for product features.

What stays private, and what still travels as metadata?

SealTask encrypts workspace content on the device before sync. The service still needs a narrow operational layer to route collaboration and reminders.

Unreadable to the service

  • Readable task titles
  • Readable task bodies and notes
  • Readable recurring-task template content
  • Readable comment bodies
  • Readable checklist content
  • Readable project titles and descriptions
  • Attachment plaintext
  • Plaintext account passwords
  • Workspace content decryption keys

Server-visible workspace metadata

  • Account email addresses and workspace or project membership identities, roles, statuses, invitation states, and access timestamps
  • Database identifiers and relationships, including project owner, task and note creators, comment authors, delegation members, attachment uploaders, and per-member task-read cursors
  • Project timezone, section identifiers and policies, section timestamps, and task position or order
  • Task priority, completion and archive state and timing; note privacy and timestamps; per-member task-read timestamps; project timestamps and archive state; note, comment, and attention counts; and workspace write or collaboration entitlement flags
  • Recurrence schedule, timezone, active state, section, iteration, next-run, last-materialized, and task-materialization timestamps
  • Comment authorship relationships, counts, and timestamps; comment bodies remain encrypted
  • Delegation membership identifiers, roles, statuses, and timestamps; delegation notes remain encrypted
  • Attachment, project, and task relationships, including task-to-attachment link timestamps; storage identifiers; ciphertext byte size (which usually approximates original file size); upload capability expiry and protocol; status; and creation, update, or deletion timestamps; attachment content remains encrypted
  • Per-membership salts and membership proofs, plus the server-held project-scoped payload-binding key used to verify or compute matching HMACs; this binding key is not a workspace-content decryption key
  • Real-time event types; event, project, actor, membership, browser-instance, affected entity, section, and order identifiers; changed-field names; occurrence timestamps; and missed-event counts

This disclosure covers encrypted workspace content and its server-visible metadata. The workspace-content metadata inventory is complete for the enumerated current workspace persistence and SQL models, API-response models, and SSE event models. It is not a complete privacy-data inventory and excludes account authentication, billing, security and audit, abuse-prevention, and service telemetry domains; those domains are described non-exhaustively in the privacy policy. Metadata can itself be sensitive. Attachment ciphertext size usually reveals an approximation of the original file size.

Timing alone can expose a confidential meeting, decision, or movement. If the timing of an event is itself confidential, keep the task in the calendar, board portal, or another approved specialist system.

Inspect the security architecture

Worked example: the board meeting moved to Thursday.

The task layer coordinates preparation. It does not become the board book, identity vault, or source of formal minutes.

SealTask

Confirm the revised agenda owner by 10:00.

An operational reminder with a due date; avoid copying the board discussion into the task.

SealTask

Collect unresolved decision owners in the board portal.

The reminder can live in SealTask; the decision record and attachments stay in the portal.

Specialist system

Board pack, minutes, and director materials.

Authoritative governance material belongs in the approved board-management system.

Specialist system

Travel identity documents and account credentials.

Keep these in approved travel tools and a password manager, never in task bodies or attachments.

A useful task says what must happen next. It does not need to reproduce every confidential fact that explains why.

What belongs here, and what remains authoritative elsewhere?

Use SealTask as the coordination layer. Keep the original record in the tool responsible for its lifecycle, retention, or access policy.

Work item SealTask System of record Why
Meeting preparation and follow-ups Yes — next action and owner Calendar, email, or meeting archive The task coordinates the handoff; the source preserves the full record.
Board papers and formal minutes Reminder only Board portal Governance records need the portal’s access, versioning, and retention controls.
Passwords, payment cards, passport details No Password manager or approved travel system Task software is not a credential or identity vault.
Temporary coverage handoff Yes — a dedicated shared list Relevant source systems Per-list access narrows the operational view without moving source records.

Four workflows that carry more context than they appear to.

These examples belong in a task layer only after you decide what the task must reveal and where the underlying record lives.

  1. 01 · Morning brief

    Prepare the decision queue.

    Track who owes an answer, which decision is blocked, and what must be ready before the first meeting. Link back to the source system instead of copying the source material.

    ExampleConfirm whether the vendor decision is ready for the 09:30 review.

  2. 02 · Meeting follow-through

    Turn verbal commitments into owned actions.

    Capture the operational next step, assign the owner, and set the follow-up rhythm without placing the full meeting record in the task.

    ExampleAsk finance owner for the revised scenario before Friday.

  3. 03 · Travel and events

    Coordinate moving parts, not identity documents.

    Use recurring checklists for approvals, transport, briefs, and arrival details. Keep passport scans, payment cards, and loyalty credentials in approved travel or credential systems.

    ExampleVerify ground transport with the approved travel provider.

  4. 04 · Sensitive handoff

    Share the smallest useful list.

    Give a temporary assistant or chief of staff one project. For fixed-term coverage, optionally choose an access-end date that matches the handoff; otherwise leave it unset and remove access manually. In Access review, inspect temporary staff, their projects, and last-active dates; at handoff, remove the assistant from all projects you manage. Revoke calendar, board-portal, and other source-system access separately.

    ExampleCoverage list: board-week logistics and owner follow-ups only.

Where SealTask fits the assistant’s operating rhythm.

The product is deliberately narrower than an executive office suite. Its job is private task coordination.

Recurring tasks without recurring plaintext

Set repeating operational work once. The task content stays encrypted on the client before sync; due dates and recurrence timing remain operational metadata.

One shared list, not blanket access

Personal (€5.90/month) adds per-list sharing. Invite a collaborator only to the list they need. Removing a collaborator revokes their server-authorized access to the project. Using access review to remove them from every manageable project applies that same server-side revocation to each project. On the server that commits the change, active real-time streams are signaled after the commit; changes committed on another server and bulk or otherwise unsignaled changes are rechecked within the current authorization lease, at most 30 seconds. Bytes already delivered or buffered by the transport cannot be recalled. The current release does not automatically rotate any affected project key or re-encrypt projects for remaining members, and removal cannot erase content or key material obtained while the collaborator was authorized. If future sensitive work needs a fresh cryptographic boundary, create a new project and share it only with current members.

Private search on the device

Search runs after local decryption in the browser. SealTask does not need a readable server-side search index of workspace content.

A €0 solo starting point

Free includes one workspace, two projects, 100 MB of encrypted attachments, and 30-day audit history. No credit card is required.

A private task layer is not an executive security program.

SealTask does not replace a board portal, password manager, document-management system, travel platform, calendar, or records-retention policy. It supports optional authenticator-app two-factor authentication (TOTP) with one-time backup codes, but is not currently SOC 2 certified.

End-to-end encryption protects workspace content from readable server access. It cannot prevent a legitimate collaborator from copying information they can decrypt, protect an unlocked device, or decide which executive details are appropriate to place in a task.

Questions this guide should answer.

Can SealTask replace an executive assistant’s inbox or calendar?

No. Email and calendars remain the communication and scheduling systems of record. SealTask holds the encrypted operational next steps around them.

Can SealTask staff read an executive’s task titles?

SealTask cannot decrypt readable task, project, note, comment, checklist, recurring-template, or attachment content, and it does not receive plaintext passwords or workspace content keys. The service can still see operational metadata such as account and membership identities, relationships, task state and timing, recurrence schedules, attachment sizes and statuses, and real-time event identifiers. Metadata can itself be sensitive; the security architecture lists the complete current workspace inventory.

Can I share work with a temporary assistant?

Yes, on a paid plan. Share only the relevant project, revoke access when coverage ends, and keep source records in the systems the temporary assistant is authorized to use.

Should passwords or passport scans go into SealTask?

No. Use a password manager and approved identity or travel systems. Encryption does not turn a task manager into a credential vault.

Does SealTask use AI to process task content?

No. SealTask does not provide server-side AI features over workspace content, and the server does not hold the keys needed to read that content.

Sources and further reading.

  1. 01

    SealTask security architecture Open page Encryption, key handling, server visibility, and recovery tradeoffs

  2. 02

    SealTask pricing Open page Current Free, Personal, Team, and self-hosted terms

  3. 03

    Best encrypted task management Open page A source-backed comparison of encryption models and product tradeoffs

  4. 04

    NIST SP 800-171 Rev. 3 — Least Privilege Open source Access should be limited to what users need for assigned work and reviewed over time

  5. 05

    FTC — Protecting Personal Information: A Guide for Business Open source Collect less, retain only what is needed, and scale access down by least privilege

Give the next action a private home.

Start with two encrypted projects on Free. Move to Personal when a trusted handoff needs per-project sharing.