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).

Personal access token secrets are never stored in plaintext; we store only a non-secret prefix and a cryptographic hash of the token.

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;
• token secrets are validated against stored hashes and are never logged;
• sensitive fields are redacted from structured logs;
• a token secret is displayed once at creation and cannot be retrieved afterward.

3. Tenant Isolation

The Service is multi-tenant. Data and configuration are scoped to a tenant (agency and organization), and requests are authorized against the tenant that owns the relevant connection, instance, and token. A connection is intended to be reachable only through its own endpoint and valid tokens.

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, instances, and tokens.

Each hosted MCP endpoint is gated by personal access tokens. A token carries its own access mode and catalog exposure, so the exposed tool set can be scoped per token, including read-only operation.

Workspace owners can additionally enable an optional account-level IP allowlist. 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 per-token authentication and is not a replacement for keeping your URLs and tokens secret.

5. Rate Limiting and Abuse Controls

Hosted endpoints apply per-token, per-minute rate limiting using fixed-window counters, with informative rate-limit response headers. 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, authentication, role-based access controls, and per-token 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;
• who you grant MCP URLs and tokens to, and rotating or revoking them when exposure is suspected;
• 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