Provider credentials
- Persistent provider credentials are encrypted before storage.
- Tokens and API keys remain server-side and are never sent to analytics.
- OAuth state and PKCE are used where supported by the provider.
- Owner-scoped database policies isolate connections and activity.
Explicit infrastructure changes
BindDock does not silently create, delete, or replace provider resources. Launch Stack presents each provider write as a separate, resumable step. Operations such as resuming a paused Supabase project require confirmation and are protected against duplicate requests.
Disconnecting is not deletion. Removing a connection from BindDock never deletes projects, repositories, domains, or deployments held by that provider.
Operational visibility
Connections distinguish live data, stored snapshots, temporary provider failures, limited access, and lost authorization. Activity records meaningful operations without recording secrets or raw sensitive provider responses.
Read-only AI access
BindDock MCP uses OAuth 2.1, PKCE, audience-bound access tokens, and a dedicated read-only database role. It exposes a fixed set of inventory and health tools—not a generic provider proxy—and cannot trigger provider writes. Every request remains scoped to the signed-in BindDock owner.
Report a security concern
Email contact@binddock.com with a concise description. Do not include passwords, tokens, keys, authorization codes, or environment files. For general help, visit Support.