// Security

Zero-knowledge encryption by default. Your tokens are encrypted with keys only you hold, backed by real cryptography.

Bindify encrypts all OAuth tokens with AES-256-GCM. By default, your tokens use client-side keys — zero-knowledge encryption where Bindify never holds the decryption key. Tokens are refreshed on-demand when your connection is used. Advanced users can opt into managed refresh mode for automatic background renewal. Here is exactly how both modes work.

// Who we are

Bindify is built and operated by Dylan Wood (GitHub, LinkedIn) at Lightsong Software Solutions, LLC, a software consultancy based in Oregon. Dylan has 17 years of software development experience, including serving as Director of Engineering for Item Page Experience at Walmart Global Tech. The company is registered in the state of Oregon.

We ask you to trust us with access to your connected services, and we take that seriously. Rather than hide behind vague assurances, this page explains exactly how the system works so you can evaluate it for yourself. If you have the technical background, you can also review the proxy source code.

// Token encryption

When you connect a service through Bindify, the credentials your service provider gives us (OAuth tokens) are immediately encrypted using AES-256-GCM and stored in that encrypted form. They are never stored in plaintext. Your secret URL contains 512 bits of cryptographic entropy — making brute-force guessing mathematically impossible.

This means:

• Encrypted at rest — your service provider credentials are never stored in plaintext
• On-demand refresh — tokens are refreshed automatically when you use your connection
• 512 bits of entropy — the math makes brute-force guessing impossible

Client-side Keys (default)

In this mode, the only way to decrypt your stored credentials is with your secret URL or API key. Bindify never stores the decryption key — it exists only in the credential you hold. Without it, your encrypted credentials are unreadable, even to us.

• Bindify employees cannot access your credentials — we don't have the decryption key
• A database breach leaks nothing usable — encrypted data without the key to unlock it
• Per-connection isolation — each connection has its own encryption key; compromising one reveals nothing about others

Managed Refresh (opt-in)

If you opt into managed refresh, Bindify also refreshes tokens in the background — useful for long-idle connections or services with aggressive token expiry. Managed connections still use AES-256-GCM encryption, but the decryption keys are stored securely within Bindify's infrastructure rather than solely in your secret URL.

Your secret URL and API key are shown once when you connect a service. We never display them again because we never store them. If you lose them, you reconnect (a new OAuth flow generates fresh credentials).

// What we can and cannot see

We want to be direct about this: Bindify is a proxy. Every MCP request and response passes through our infrastructure. We believe you deserve to know exactly what that means.

We make this claim, but we also know that claims are cheap. That is why the proxy worker source code is available for you to read. If you want to verify that we do not log payloads, you can check the code yourself.

View the proxy source code on GitHub →

// API key authentication

In addition to secret URLs, Bindify offers API key authentication for programmatic access and CLI tools like Claude Code.

The API key provides identical security guarantees to the secret URL:

• Same encryption — AES-256-GCM, same storage mode as your connection
• Never stored — shown once after OAuth, then discarded
• Same revocation — revoking a connection invalidates both the URL and API key

When to use which:

• Secret URL — Claude Desktop, Claude.ai, Cursor, and other MCP clients (simpler, single value)
• API key — Claude Code CLI, programmatic access, any tool that supports Authorization headers

Both methods are equivalent. Choose whichever fits your client.

// The math: 512 bits of entropy

Every Bindify secret URL and API key contains 512 bits of cryptographic randomness:

To put that in perspective:

// What we do to protect you

// Honest risk assessment

The URL itself is the credential. Treat it like a password:

• Do not share it publicly
• Do not commit it to public repositories
• If you suspect it has been exposed, revoke it immediately from your dashboard

This is a deliberate trade-off: permanent convenience in exchange for treating a URL as a secret. We believe this is the right trade-off for most users, and it is the same model used by thousands of production APIs and webhooks across the industry.

// Your data lifecycle

You control your data. Here is exactly what happens at each stage:

// Credential rotation

All connections (including OAuth with client-side keys) refresh tokens on-demand when used. If you opt into managed refresh, tokens are also renewed in the background.

Connections should be rotated annually for security. Click "Re-authorize" in your dashboard before the 1-year mark to keep your connection active.

// Incident response

If we ever discover unauthorized access to our systems or your data, we commit to the following:

• Notification within 72 hours — affected users will be notified by email with details of what happened, what data was involved, and what actions we are taking
• Immediate credential rotation — all potentially affected tokens will be revoked and connections will require re-authorization
• Public disclosure — we will publish a post-mortem on our blog describing the incident, root cause, and remediation steps

We have never had a security incident. We intend to keep it that way, but we also believe that having a plan matters more than hoping you never need one.

// Privacy & compliance

• We do not sell, share, or monetize your data in any way
• We do not serve ads or allow third-party tracking in our application
• We collect the minimum data needed to operate the service: your email, encrypted tokens, and connection metadata
• You can request data export or deletion at any time by emailing security@bindify.dev
• Full details are in our Privacy Policy and Terms of Service

// Vulnerability disclosure

If you discover a security vulnerability in Bindify, please report it responsibly:

We ask that you give us reasonable time to address the issue before public disclosure. We will credit researchers who report valid vulnerabilities (with your permission).