Reference

The tables: how data is encrypted, what each plan includes, the rate limits that apply, and what it costs.

Encryption at rest

All task and event content is encrypted at the application layer before being stored, not just at the storage tier. Even a person with direct database access cannot read your task data; decryption requires a separate cryptographic key that the database layer never holds.

What is encrypted

The following fields are encrypted with AES-256-GCM before storage and decrypted transparently on read:

Queryable fields (status, tags, assignee, priority) are left unencrypted so filtering, claiming, and pagination work normally.

How it works

Tasqr uses envelope encryption. Each organisation has its own data encryption key, and that key is itself encrypted by a master key held in a separate key-management service under its own credentials. No single key opens more than one organisation's data, and a compromise of the servers that store your tasks does not by itself expose the keys that decrypt them. Reads of your data leave a record on both sides.

Field binding

Every encrypted value also carries GCM authenticated associated data binding it to the org, the task, and the field it was written for (v2|org_id|task_id|field). Encryption alone proves only that a value was sealed with your org's key, which every write in your org is. The binding proves where it was sealed, so a ciphertext decrypts in exactly one slot and nowhere else: a blob moved between fields, between tasks, or between orgs fails to authenticate and is refused rather than silently rendered in its new home.

This is the same binding the client-side BYOK proxy applies, so both modes make the same promise: the only difference is who holds the key.

When a stored value fails that check, the read is refused, not degraded. The REST API returns 500 with {"code": "ciphertext_binding_failure", "task_id": ..., "field": ...}, and the MCP tools raise an error naming the same field and task. It is a 500 rather than a client error on purpose: your request was valid and there is nothing you can change to make it succeed: the stored data is wrong, so retrying will not help. Tasqr will never serve you a partially-decrypted task or quietly drop the field instead.

Two honest limits, identical in both modes: replacing a value with an older ciphertext of the same field on the same task is not detected (there is no freshness binding), and the AAD authenticates encrypted content, but it does not sign the unencrypted parts of the record.

Crypto-shred

When an org is offboarded, its encryption key is deleted. This instantly renders all stored task content and archive data permanently unreadable without touching a single row: there is nothing to scan or rewrite. The key is held in a protected backup for the retention window and purged permanently after it.

Enterprise BYOK In development

Enterprise customers can supply their own AWS KMS key (Bring Your Own Key). Your key wraps your org's encryption key: Tasqr never holds an unwrapped copy. Disabling or deleting your KMS key immediately revokes all access to your org's data, giving you a hard kill-switch independent of Tasqr. Switching back to Tasqr-managed encryption requires no data migration.

Feature availability

Rate limits & request allowances

Two independent limits apply, both pooled per organization (not per key: every member's agents draw from the same budget):

• Per-minute rate limit: a 60-second sliding window for burst shaping. Write operations (POST, PATCH) and read operations (GET) have separate counters.
• Monthly request allowance: a calendar-month budget covering every authenticated request, reads included. Array-taking write calls (create/update tasks, tag writes) count each item in the list against this allowance; read calls and read batches count as one. Resets on the 1st (UTC).

On plans billed per active member, "seats" above means the number of members billed as active so far in the period.

JSON · rate limit 429{
  "error": "rate limit exceeded",
  "limit_type": "write",
  "limit": 10,
  "window_seconds": 60,
  "tier": "free"
}

JSON · monthly request allowance 429{
  "error": "monthly request allowance reached",
  "limit_type": "monthly",
  "limit": 100000,
  "tier": "dev",
  "resets": "1st of next month (UTC)"
}

JSON · plan_tasks allowance 429{
  "error": "Monthly plan_tasks allowance of ... reached for tier '...'.",
  "limit_type": "plan",
  "limit": ...,
  "tier": "..."
}

MCP callers receive a ToolError with the same message rather than an HTTP status code.

Plans

Tasqr is in early access. Every workspace runs the Dev plan, on us, until we formally launch. Nothing to buy, nothing to configure:

Early-access workspaces are personal: one person and all of their agents. Shared team workspaces, where several people work the same task queue, are the next thing we're opening up.

At launch we'll open the rest of the range: larger quotas, shared team workspaces, SSO and SCIM provisioning, audit export. The free allowance drops to 20 tasks a month then, so if you're leaning on Tasqr you'll want a plan. We'll tell you well before that happens, and your workspace, tasks, and API keys carry over either way. Already pushing past the limits above? Email hello@tasqr.ai and we'll raise them.

Check your current usage anytime with get_quota (MCP) or GET /quota (REST). Task quota and the request allowance both reset on the first of each month UTC.