Security
The controls we have — and the gaps we haven’t closed.
Every request — a click, a REST call, an MCP tool call — resolves the same authorization pipeline, and a token’s authority is its scopes intersected with the workspaces you name. What we don’t have yet is named further down, not left for you to infer.
Web UI, REST API and MCP all resolve the same one.
Reachable by any token — including minting more tokens.
Chosen per token. Revocation is immediate.
MCP endpoint limit. Over it returns HTTP 429.
01 — The model
Three front doors, one corridor
The interface is not privileged over the API, and the API is not privileged over the assistant. They are the same code path, checked in the same order.
Enters as
- Web interface
- REST API
- MCP tool call
The authorization pipeline
- Resolve which workspace the request is for.
- Reject it if that workspace is not on the token’s allowed list — before any handler runs.
- Intersect the token’s scopes with the permission the operation requires.
- Run the same handler and the same validation a click in the app runs.
- Write under optimistic concurrency, and record the activity.
Which is why
- No second, looser path in.
- An activity record for every mutation.
- A merge path instead of a silent overwrite.
02 — What is true today
Control, and how it is enforced
13 controls that exist in the product now. Each one names the mechanism, so you can ask us to demonstrate it rather than take the row on faith.
| # | Control | How it is enforced |
|---|---|---|
| Access and identity | ||
| 01 | One authorization pipeline | A click in the web app, a REST request and an MCP tool call take the same path: same permission checks, same validation, same handlers. There is no faster route with weaker checks. |
| 02 | Token authority | A token can do exactly its scope set intersected with its explicit list of allowed workspaces. Nothing widens that at runtime, and membership roles are not consulted for MCP. |
| 03 | Workspace boundary | The pipeline resolves the workspace of each request and rejects it if the workspace is not on the token’s list — before any handler runs. |
| 04 | Administrative ceiling | No token can perform a super-admin action, including minting further tokens. That is enforced in the pipeline rather than left to configuration. |
| 05 | Token secrets | Stored as PBKDF2 hashes alongside a short display prefix. The secret is shown once at creation and is not recoverable afterwards — by you or by us. |
| 06 | Token lifetime | Every token carries an expiry between 1 and 365 days, records when it was last used, and can be revoked immediately. |
| 07 | Destructive scopes | Deletion sits behind its own scope, separate from write access, so a token that can create and update tasks cannot delete them. |
| 08 | Rate limiting | The MCP endpoint at api.planner.day/api/mcp is limited to 120 requests per minute per token, returning HTTP 429 above it. Per token rather than per user, so one noisy automation cannot starve another. |
| Data and change | ||
| 09 | Tenant isolation | Records are scoped by workspace, and every query is filtered by the caller’s membership rather than by a workspace id the client supplied. |
| 10 | Deletes | Soft by default. The row is retained and recoverable, so an accidental removal is not terminal. |
| 11 | Audit trail | Every mutation writes an activity record, whoever made it — a person in the UI, an API client, or an assistant over MCP. |
| 12 | Concurrent edits | Optimistic concurrency control. A write against a stale version is refused and offered a merge path, instead of silently overwriting somebody else’s edit. |
| 13 | In transit and at rest | All traffic is served over TLS. Data is stored in PostgreSQL with encrypted volumes and automated backups. |
The token model is documented in full, scope by scope, on the MCP server page.
03 — What we do not have yet
The part most vendors bury
4 things buyers reasonably assume, that we do not offer. Stated here so nobody has to infer them from silence — or discover them at the end of a procurement cycle.
Not available
There is no SOC 2 report, ISO 27001 certificate or equivalent third-party audit to send you. If your procurement process requires one, Planner.day does not pass it today.
We do not publish an uptime commitment or a service-credit scheme. Availability is something we work at, not something we have contracted to.
There is no supported, documented self-hosted deployment. Planner.day runs as a hosted service, so your data lives on our infrastructure.
Disclosure is welcome and answered, but there is no bounty programme and no payout. We would rather say so than imply one.
Nothing on this page is aspirational. If a control is in the table above, it is in the product today; if it is in this panel, it is not.
04 — Responsible disclosure
One address, answered by a person
If you have found something, we would rather hear it from you than from a customer. There is no form and no portal in the way.
Include, if you can
- The URL, endpoint or tool call affected.
- Steps to reproduce, in the order you took them.
- What the issue let you reach that you should not have.
- Whether any real data was viewed, and whose.
What happens next
- We reply to every report. Not an auto-responder — an answer.
- Safe harbour. We will not pursue action against good-faith research that avoids privacy violations, data destruction and service degradation.
- No payout. There is no bounty programme, as listed above. Credit where you want it, money we do not have a scheme for.
Please keep testing to accounts and data you own — the three limits above are what “good faith” means here.
Anything this page doesn’t answer, ask directly: contact. Changes to the product are logged on the changelog.