Security overview

Last updated July 3, 2026

Trove sits between Claude and the tools you give it — that's the product, and it's a position that deserves scrutiny. This page explains what Trove can see, what it can't, and how the system is built so that the blast radius of any one piece stays small.

What Trove sees, plainly

When Claude calls a tool through your connection, Trove executes that call: it sees the tool name, the arguments Claude sent, and the result the upstream source returned. That's inherent to being the runtime. What we do with that position is the subject of everything below — and the short version is: your data is partitioned per user at every layer, credentials are sealed away even from our own UI, and each toolkit runs in a sandbox that can reach only the hosts it declared.

What persists is what you'd expect: your configuration and anything you save to your library. Tool arguments and results are not stored — they pass through in memory to serve the call. Short-lived operational logs used for debugging and abuse prevention expire automatically within seven days — and the code paths that handle tool calls and credentials write no payloads or secret values into them.

Per-user isolation

Every account gets its own store — not a row in a shared table, but a dedicated per-user Durable Object with its own private SQLite database. There are no cross-tenant queries because there is no cross-tenant table to query. File storage and the shared search index are partitioned by user the same way: every stored object is keyed to your account, and every search query carries a mandatory per-user filter enforced in one code path.

Credentials: a write-only vault

Some toolkits need an API key (most don't). Keys you provide are sealed into an envelope-encrypted vault: each secret is encrypted with its own AES-GCM data key, which is itself wrapped by a root key. The root key lives as a Cloudflare Workers secret — available only to the deployed runtime, never in the codebase, the database, or any dashboard. The database holds only opaque references, never values.

The vault is write-only by design: you can set, rotate, or remove a credential, but nothing — not the dashboard, not the API, not our support tooling — can read one back. The UI shows presence ("Set ✓ · updated <date>"), never the value. Secret values never touch the database or the event log, nothing in the call path writes them to logs, and a credential is decrypted only at the moment a tool call needs it, then handed only to the toolkit that declared it.

Toolkits run sandboxed

Each toolkit executes in an isolated sandbox with a short-lived, narrowly-scoped token — minted per call, expiring in seconds, carrying only that toolkit's permissions and secret names. Network egress is restricted to the exact hosts the toolkit declares in its manifest, with SSRF hardening on top (HTTPS only, IP-literal and internal-address blocking); a toolkit for arXiv can talk to arXiv and nothing else. Failures are isolated too: a broken toolkit returns an error for its own tools and cannot take down your connection or anyone else's. Every official toolkit's code and declared hosts are open source — read the arXiv toolkit's manifest (or any other) to see exactly what runs and where it's allowed to connect.

You hold the switches

Toolkits are off until you enable them, and disabling one removes its tools from your connection immediately. Every tool call is visible in Claude's own UI as it happens — nothing runs silently. Deleting your account purges your per-user store, stored files, credentials, and connection state.

An honest note on combining tools

Any setup that gives an AI both web-content tools and action tools (like sending email) carries prompt-injection risk — content fetched from the web could try to steer the model into misusing an action. This is true wherever an AI is given tools this way, not just Trove. Our advice: enable action toolkits only while you're using them, and rely on Claude's per-call visibility and permission prompts. We build toolkits with least-privilege scopes so the damage a bad instruction could do stays bounded.

Reporting

Found a vulnerability, or something that doesn't match what this page says? Email us — reports go straight to the person who wrote the code, and every one gets a reply. Machine-readable contact details live at /.well-known/security.txt.