Security
The MCP server acts inside your workspace on your behalf, so it's built around least privilege and explicit consent.
Two safety layers
Every action that changes data passes through two independent gates:
- Per-key scopes. A key only carries the scopes you grant it. A
workspace:readkey physically cannot write, send, or trigger anything; the server refuses before the tool runs. See Authentication & scopes. - Host confirmation. Destructive tools declare
destructiveHint: true, and compliant hosts (Claude Desktop, Cursor) prompt you before each one. The AI can't silently send an email or delete data.
To shut everything off instantly, revoke the key (effective within 60 seconds).
What leaves your workspace
A tool returns exactly the data you asked for (the rows you queried, the asset list you requested) and nothing else about your workspace is sent to your AI host. The server runs each call as you and respects the same per-asset permissions you have in the web app, so a key can never reach data you yourself can't.
Tiny Command tables don't store row-level revision history, so a record overwritten by update_record can't be auto-restored. Treat workspace:execute access the way you'd treat giving an app edit rights to your data, and prefer scoped keys for anything you don't fully control.
Key hygiene
- The full secret is shown once, so store it in your host's config or a secret manager, never in shared docs or chat.
- Use a separate key per host or machine, so you can revoke one without disrupting the others.
- Rotate keys periodically: generate a new one, update your host, then revoke the old one.
- Watch the audit log for activity you don't recognize.
Reporting a vulnerability
Found a security issue? Please report it privately to security@tinycommand.com rather than filing a public issue. We'll acknowledge and work with you on a fix.