Security Overview

1. Encryption at Rest and in Transit

Provider credentials are encrypted at rest using AES-256-GCM before they are stored. Network communication with the Service is protected in transit using industry-standard transport encryption (TLS).

OAuth refresh tokens and client secrets are never stored in plaintext; we store only a cryptographic hash. Access tokens are short-lived signed tokens that expire after an hour and are not stored.

2. Credential and Token Handling

We minimize exposure of sensitive material throughout its lifecycle:

• provider credentials are decrypted only when needed to verify a connection or perform an authorized operation;
• refresh tokens are validated against stored hashes, rotate on each use, and are never logged;
• sensitive fields are redacted from structured logs;
• reusing a refresh token that has already been spent revokes every refresh token held by that client for that user.

3. Tenant Isolation

The Service is multi-tenant. Data and configuration are scoped to a tenant (agency and organization), and every request is checked against the signed-in user's membership, workspace, and connector access before it runs.

4. Authentication and Access Controls

User sign-in uses Google OAuth through our authentication provider, with signed session cookies. Within a tenant, role-based controls govern who can manage members, connections, and instances.

The hosted MCP endpoint is gated by OAuth 2.1 with PKCE. When a user authorizes an AI client, they choose which connectors that client may reach. On plans that include per-member access control, the owner sets each teammate to read-only or full access, and curated or full catalog, per connection; on other paid plans teammates other than the owner are read-only, and the Free plan is read-only for everyone.

On eligible plans, the account owner can additionally enable an optional account-level IP allowlist of up to 50 entries. When it is enabled with at least one entry, the Service only accepts requests to the account's hosted MCP endpoints from the IP addresses or ranges the owner has listed (IPv4 and IPv6, including CIDR ranges), across every workspace in the account. The allowlist is most effective for clients that connect from stable addresses such as offices, VPNs, or servers; hosted AI clients may connect from changing provider addresses that are harder to restrict. When the allowlist is empty or disabled, all addresses are allowed, so the control cannot accidentally block every connection. It is one optional layer alongside OAuth authentication and is not a replacement for authorizing only the AI clients you trust.

5. Rate Limiting and Abuse Controls

Unauthenticated requests to hosted endpoints are rate limited per IP address, and a request over the limit receives a Retry-After header. Rate limiting helps protect the Service and connected providers from overload and abuse, but it does not replace the limits and protections enforced by each provider.

6. Logging, Telemetry, and Redaction

We record usage and operational telemetry to support reliability, security investigation, rate limiting, and billing. Usage events capture metadata such as method, tool name, outcome, latency, byte sizes, client name, and a hashed network address rather than a raw IP.

Telemetry is not intended to include provider credential values or token secrets, and sensitive values are redacted from logs.

Where a workspace owner uses the optional IP allowlist, the Service additionally records the IP addresses of recent authenticated connections to the account's endpoints so the owner can review and configure allowed addresses. These recent connection IP addresses are shown only to authorized workspace owners and are retained for a limited period before deletion.

7. Shared-Responsibility Model

Security is a shared responsibility. The following summarizes what PopMCP works to secure and what remains your responsibility.

What PopMCP works to secure

• encryption of stored provider credentials and hashing of token secrets;
• tenant isolation, OAuth authentication, role-based access controls, and rate limiting;
• secret redaction in logs and operational monitoring of the Service.

What you are responsible for securing

• which credentials you connect and the scope of access those credentials carry at the provider;
• which AI clients you authorize and which connectors you approve for each, and removing members who no longer need access;
• whether you enable write access or the full operation catalog, and using read-only mode where appropriate;
• what your AI clients and agents are permitted to do, and supervising consequential or destructive operations;
• configuring and maintaining optional access controls such as the IP allowlist, including keeping listed addresses current so that your own legitimate clients are not blocked;
• your provider-side configuration, backups, and compliance with each provider's terms and limits.

Because operations performed through your endpoints and tokens can write, modify, or permanently delete data in your connected accounts, PopMCP is not responsible for the consequences of those actions. Responsibility for them is allocated to you under our Terms and Conditions.

8. Vulnerability Reporting

We welcome responsible disclosure of security issues. If you believe you have found a vulnerability, contact security@popmcp.com with enough detail to reproduce the issue. Please do not access data that is not yours, degrade the Service, or publicly disclose an issue before we have had a reasonable opportunity to address it.

Do not include live provider credentials or token secrets in your report. Use redacted examples where possible.

9. No Warranty

No security program can guarantee absolute security, and this overview does not create any warranty or guarantee. The Service is provided on an "as is" and "as available" basis, and our warranties, disclaimers, and limitation of liability are set out in our Terms and Conditions.

10. Contact

Security questions or reports may be sent to:

PopMCP

security@popmcp.com