Security

This page describes how AllMCP is built, what we store, what we deliberately don't, and what happens when you revoke access. It's written for engineers evaluating us. If anything here is unclear or you think we've missed something, email security@allmcp.co.

Architecture: a relay, not a database

AllMCP is a multi-tenant MCP endpoint (https://go.allmcp.co/mcp/) that sits between your AI agent and the SaaS providers you connect — Bitrix24, Google Sheets, AmoCRM, YouGile, and others. When your agent calls a tool, we look up your encrypted credential for that provider, forward the request upstream, and return the response to your agent. The response passes through; it is not persisted. We do not store the content of tool calls — no CRM records, no spreadsheet values, no messages ever land in our database. This is our core security property, not a policy promise layered on top: data we never store cannot be exposed by a breach of our storage, leaked by a bad query, or subpoenaed out of a backup.

Encryption

• Provider credentials (the OAuth tokens and API keys for your connected SaaS accounts) are encrypted at rest with AES-256-GCM. They are never written to logs, and they are decrypted only to serve your own tool calls.
• All traffic to and from AllMCP uses TLS 1.2 or higher in transit.
• AllMCP API keys are stored only as SHA-256 hashes. The raw key is shown exactly once, at creation. We cannot display it again — if you lose it, you rotate it.

No passwords

Sign-in is passwordless: Google or GitHub OAuth only. We never create, accept, or store a password for any account. There is no password database to breach, no hashes to crack, and nothing for a phishing page to harvest that would work against us directly.

Tenant isolation

Accounts follow a strict Client → Organization → User hierarchy, and provider credentials are stored per user — a tool call resolves to exactly one user's credential and can never reach another tenant's. The credential cache (DragonflyDB) runs inside our VPC and is not exposed to the internet. Cache keys derived from API keys are SHA-256 hashed; raw keys never enter the cache.

What we log — and what we never log

Usage logs contain metadata only:

• client, organization, and user identifiers
• provider and tool name
• call duration and status

We never log tool-call request or response payloads, provider credentials, tokens, or API keys.

One honest caveat: when an upstream provider returns an error, we store the provider's error string, truncated to 1,000 characters, so we can debug failures. Provider error messages occasionally quote fragments of the request that triggered them (a field name in a validation error, for example). That is the one place where a sliver of content can appear in our logs, and we'd rather tell you than pretend otherwise.

Error events sent to Sentry are scrubbed before leaving our systems by an extended denylist scrubber that strips tokens, keys, and personal data.

Public by design: the tool catalog

Our tool catalog — the list of providers, tools, and their schemas — is intentionally public and available without authentication. Agents need to discover what AllMCP can do before anyone connects anything. The catalog contains zero customer data: no credentials, no connections, no usage information. Discovering that a bitrix24_list_contacts tool exists tells you nothing about who uses it.

Revocation guarantees

• API keys: revoke in the dashboard; the key is dead immediately.
• MCP connector grants (OAuth 2.1 tokens we mint): refresh tokens are tracked server-side, so revocation takes effect immediately for any new refresh. Already-issued access tokens expire on their own within 60 minutes at most. Practically: revoke a grant and the connection is fully dead within the hour, usually much sooner.
• Account deletion kills API keys and connector grants immediately, with a hard purge of remaining account data after a 7-day grace window.

Availability

We run on AWS in the United States, in a single region today. We won't dress that up: there is no multi-region failover yet, so a serious regional AWS outage would take us down with it.

Responsible disclosure

Found a vulnerability? Email security@allmcp.co. We respond within 72 hours.

Safe harbor: we will not pursue legal action against good-faith security research. Good faith means: don't access, modify, or destroy data that isn't yours; don't degrade the service for other tenants; and give us reasonable time to fix the issue before disclosing it publicly.

No bounty program yet. We're a small team and we don't currently pay for reports — we say that up front so there are no surprises. We still want your report, and we take every one seriously.