Security and daily use - MCP
Key permissions
Every MCP key gets its own set of permissions, independent of other keys on the same account:
| Permission | What it unlocks |
|---|---|
monitoring.read | alerts and daily monitoring statistics |
projects.read | the project list and its current state |
projects.write | creating and editing projects |
projects.delete | deleting projects |
issues.read | the error list - group metadata only |
issues.details | full error content: message, failing location, stack |
issues.write | changing an error's status |
issues.delete | deleting errors |
A tool the key lacks the matching permission for does not appear in the tools/list response - that is not a hidden option, it is the absence of the tool from that key's point of view.
issues.details is the exception
This is the only permission unticked by default, because it exposes data more sensitive than the rest: without it, issues.list returns only group metadata (project token, type, status, event count, dates), and the issues.get tool does not exist for that key at all. With it, the list also gets the error message and failing location, and issues.get returns the full picture of one group - including the stack trace, code-carrying frames, request data and daily history. Tick it deliberately, once a tool actually needs to diagnose errors rather than just count them.
A key's scope is the intersection with its issuer's permissions
A key does not live on its own - on every request its stored permissions are intersected with the current permissions of the person who issued it. Demoting that person or deactivating their account narrows or invalidates the key from the very next request, with no extra action needed. The narrowing only affects the in-memory read - the key's row in the database stays untouched, so restoring the issuer's former permissions immediately restores the key's full scope.
What the MCP server never returns
Project data never includes private keys, and error details never include an e-mail address, username, user id or IP address taken from the client payload. Request headers go through an allow-list, not a deny-list - a new authentication header a client starts sending does not leak just because no one has added it here yet; the count of skipped headers travels in the response as headers_omitted. Stack frame local variable values never go out at all, and source code is attached only to frames belonging to the client application.
Auditing and rate limits
Every tool call lands in the audit log together with the IP address stored as a hash. A request whose Origin header points to a foreign domain ends in 403 - a browser has no business here, this endpoint is for server-side clients. The request rate limit is keyed by the token hash, so one overloaded client does not eat into the limit for the account's other keys.