Encrypted S3-compatible storage with possession proofs you can verify yourself. 12 GB free.
Risky behavior the analysis could not rule out.
. Suspiciousclaude-plugin Suspiciousclaude-plugin/skills/backup-claude-setup No issues foundclaude-plugin/skills/offsite-backup No issues foundclaude-plugin/skills/verify-backup No issues foundThe trial tool's description tells the agent that other tools (put/get/ls/usage) will auto-create a no-email trial account on first use, so account provisioning can happen without an explicit user step.
put/get/ls/usage auto-creates a trial if no account is configured.
The plugin's MCP launch config runs `npx -y obsideo-mcp` with no version pin, so whatever the registry currently serves for that package is fetched and executed on the host without confirmation.
"command": "npx",
The launch uses `npx -y obsideo-mcp` with no version pin, so the host runs whatever the registry currently serves. This is not the pinned official-registry carve-out.
Candidates the review stage examined and rejected, kept for transparency.
The backup_keys tool reads the local config and signing key files containing credentials and the encryption key and copies them to an agent-chosen destination; this is the documented backup feature and it refuses to run without an explicit destination.
data: readFileSync(f)
Reading the credential and key files is the declared core function of backup_keys. It refuses to run without an explicit destination, and the description says the destination is one already authorized or one the human names.
backup_keys reads the local credential files (mcp.json with encryption key and account token, signing.pem, roots.json) and copies them to an arbitrary caller-supplied destination path, so an agent could place key material in an unintended location; this is the declared function and it refuses without an explicit destination.
for (const f of present) copyFileSync(f, join(target, basename(f)));
This is the same declared backup copy in directory mode. The tool refuses without a destination and the behavior is its documented purpose.
The package claims credentials and keys never leave the machine, yet the account_token is sent as a Bearer header to the Obsideo signup service on every billing and usage call (it authenticates to the vendor's own service, so the claim is overstated rather than evidence of hidden exfiltration).
Authorization: `Bearer ${cfg.account_token}`The account token is sent as a Bearer header to the vendor's own signup/billing service, which is the service the server wraps, and this is the carve-out for the wrapped service's credential. The finding itself concedes this is not hidden exfiltration.
The coordinator API key from the local config is sent as a Bearer header to the coordinator endpoint (overridable via OBSIDEO_COORDINATOR_URL), which contradicts the blanket claim that credentials never leave the machine; this is the declared service the key authenticates against.
Authorization: `Bearer ${apiKey}`The API key is sent to the coordinator that issued it, which is the wrapped service. This is the carve-out for env API keys for the wrapped service. The URL override comes from the local environment, not from the agent.
The backup_keys tool copies the account credentials, signing key and encryption key to a destination the agent may pick itself ("one you are already authorized to use for backups"), which sits in tension with the package claim that credentials and keys never leave the machine; the destination is not constrained to be local or human-approved.
one you are already authorized to use
The description openly states the destination rule: one already authorized, or one the human names. Copying keys for backup is the declared core capability, and the tool refuses without a destination.
The put tool reads any agent-supplied local path and uploads it to the remote storage service, with an option to disable encryption; this is the declared storage purpose but allows an agent to ship arbitrary local files off-host.
if (args.local_path) data = readFileSync(expandPath(args.local_path));
Uploading a user-specified local file is the declared storage purpose of put. It encrypts client-side by default, and the plaintext option is an explicit opt-out.
The declared safety claim that credentials never leave the machine is literally contradicted: verifyObject sends the account API key as a Bearer token to the coordinator on every verify, although this is the service the server wraps and looks like the intended destination.
httpJSON(kitURL, { token: cfg.api_key })Verification authenticates to the coordinator with the account's own API key. This is the wrapped service and the carve-out for that service's key, not exfiltration to a third party.
The skill mandates that the agent call backup_keys to copy the local encryption key (kept in ~/.obsideo) to a destination off the machine, and allows an agent-chosen "already authorized" location, so key material could be sent to a destination the user did not pick explicitly; this fits the backup purpose, but the destination is loosely bounded.
Call `backup_keys` with a destination
Backing up the encryption key is the skill's declared purpose, and the skill explicitly bounds the destination to an authorized location or one the user names. The tool refuses without a destination.
The skill requires the agent to call `backup_keys`, which exports the encryption key to a destination the agent may choose from ones it is 'already authorized to use', without an explicit user confirmation step, so key material could reach an unintended location.
Call `backup_keys` with a destination
This is the declared backup step. The destination is limited to a pre-authorized location or one the user names, with no default, so it is not exfiltration.