How we protect your data

• OAuth credentials are encrypted at rest with AES-256-GCM envelope encryption — every row gets its own data key, wrapped by a master key held outside the database.
• Tool access is gated per-user, per-tool, with read / write / destructive labels. Admins can keep read access on while disabling writes.
• Every tool call is recorded in an append-only audit log with actor, server, tool, and outcome.
• Hosted on Cloudflare Workers and Neon Postgres in the United States. Stripe handles billing — payment card data never touches our systems.

We use envelope encryption for every OAuth token we hold on your behalf. The scheme has two layers:

• Per-row data encryption keys (DEKs). Each stored token gets a freshly generated 32-byte random key. The token is encrypted with that key using AES-256-GCM with a random 96-bit IV.
• Key encryption key (KEK). Each DEK is itself encrypted with a master AES-256 key held in environment-isolated configuration, separate from the database. The wrapped DEK is stored alongside the ciphertext.
• Rotation. The KEK supports a primary/secondary configuration. During rotation, both keys are accepted for decryption while only the new key is used for new writes. A leaked database snapshot is unreadable without the KEK.
• Independent blast radius. Providers that issue both a workspace token and a per-user token (for example, Slack) get separate DEKs per token, so a single compromised DEK does not cross-contaminate.

Sign-in tokens (the OAuth id and access tokens issued by Google when a user signs in) are discarded after identity verification — they are never persisted. The only credentials we store long-term are the access and refresh tokens needed to call the integrations you have explicitly connected (Slack, GitHub, Jira, etc.), and those are encrypted as described above.

Tokens are decrypted in memory only when an MCP tool call needs them, and they are never written to logs or echoed in error messages.

Sign-in is via Google OAuth or email magic links (Resend). We do not store passwords. Sessions are database-backed — the cookie holds an opaque session id, not a JWT, so revocation takes effect immediately.

Each integration tool ships with a label — read, write, or destructive. Org admins can disable any subset for any user. A common configuration is to allow read across the team while restricting write and destructive tools to a smaller group, without disabling the integration entirely.

Every tool invocation produces an audit record: who called it (user, Claude on behalf of a user, or the system), which server and tool, the outcome (success / failure), a timestamp, and structured metadata. Records are append-only. On request we can export your organization's log to CSV.

Today, each user account belongs to a single organization. Servers are scoped either to a personal account or to an organization, and every database query is scoped by owner — there is no path that returns another tenant's data based on user input. Soft-delete flags are used so that org removal is reversible during a grace window.

We rely on the following service providers:

• Cloudflare — application hosting (Workers) and TLS termination. All traffic between your browser and McPortal is over HTTPS.
• Neon — Serverless Postgres. Customer data is stored in the United States and encrypted at rest by Neon, in addition to our application-level envelope encryption.
• Stripe — billing. Card data is collected by Stripe Checkout and never touches our infrastructure. We store only the Stripe customer id and subscription status.
• Resend — transactional email (sign-in links, invites).
• Google — sign-in via Google OAuth (optional).

• Tool-call payloads (prompts and full responses) beyond audit metadata.
• Passwords — sign-in is OAuth or email link only.
• Payment card numbers — Stripe holds those.
• OAuth id / sign-in access tokens once identity is verified.

Customer-managed keys are on the roadmap for enterprise customers who require control of the KEK that wraps their data. If this is a procurement requirement, contact us at security@orchestrategies.com and we will work through your requirements.

We are preparing for SOC 2. An internal audit aligned to the SOC 2 Common Criteria has been completed, and the controls — across access management, system operations, change management, and vendor governance — are being implemented against a written set of policies and runbooks. We are targeting a Type II observation period in the second half of 2026.

Customers and prospects evaluating us under procurement review can request our internal control documentation — incident response, change management, access control, data retention, KEK rotation, vulnerability management, and vendor management — by emailing security@orchestrategies.com.

To set expectations, the following are not yet in place:

• SOC 2 Type II attestation — preparing for SOC 2; see the section above.
• Public status page — planned.
• SAML / SSO sign-in — available on request for enterprise.
• Customer-managed keys — see above.

If you believe you have found a security issue, email security@orchestrategies.com. We aim to acknowledge reports within two business days. Please give us a reasonable window to investigate before public disclosure. We do not currently run a paid bounty program but will publicly credit researchers who request it.