Feature Request: permission scopes for local API keys (e.g. write without permanent delete)

Refworkbench

First, thank you for write support in the local API in Zotero 10 – it makes local tools (including MCP servers for AI assistants) much more useful than going through the web API.

While setting this up carefully, I noticed an asymmetry that I think matters for safety:

1. A DELETE through the local API erases items permanently and bypasses the trash (consistent with the web API; in the code the object is erased directly). Moving items to the trash is possible via `deleted: 1`, which is reversible.
2. Any local API key covers every write method, including DELETE. With "Always Allow", the key is remembered, and any process running under the same user account can use it – not only the application that requested it.
3. Web API keys can be restricted (e.g. read-only, per-library permissions). Local API keys have no such scopes.

In practice this means that granting persistent write access to a local tool also grants the right to erase the library permanently, with no way to separate the two.

Suggestions, in order of importance:

A. Permission scope chosen in the authorization dialog, at least "Write (no delete)": DELETE requests with such a key would be rejected (e.g. 403), while trashing via `deleted: 1` would still work. That would make "Always Allow" a reasonable choice for assistant-type tools, because deletions would stay recoverable from the trash.

B. A list of granted local API keys in the settings, with app name, scope, creation and last-use date, and per-key revocation (today the revoke button removes all write access at once).

C. Optionally, a simple log of local API write requests (time, app name, method, object count), so users can see what a tool actually changed.

A alone would already solve the main problem. I looked at the current development code and didn't see anything similar yet – apologies if it is already planned for Zotero 11. Would something like this fit into the plans for the local API?

Thanks again for Zotero.

Thomas

dstillman

A client that could write but not permanently delete could do just as much damage — it could blank out all notes, erase metadata, replace files, etc. The real protection against misbehaving clients is to not give access to clients you don't trust, and to make sure you have regular backups of your Zotero data directory, like any other important data, synced or not.

any process running under the same user account can use it

A malicious tool on the system that's going to read local API keys out of the profile directory could just as easily delete your zotero.sqlite files.

(There's a fairly common request for finer-grained permissions like this in group libraries via the web API, but that's a pretty different situation, where people fail to realize they're deleting shared data.)

Refworkbench

Thanks for the clear explanation — that makes sense. You're right that a client allowed to write but not permanently delete could do just as much damage by overwriting notes or metadata, and that a malicious local process wouldn't need a key at all.

In my case the concern isn't malware but an AI assistant (via an MCP connector) making a mistake. For that, I'll stick with approving each write request individually rather than granting a persistent key, and keep regular backups of the data directory, as you suggest.

I'll consider the request answered. Thanks again for taking the time.