RevSure MCP Server — Security & Data Handling Guide

A reference for IT, security, and privacy teams evaluating the RevSure MCP (Model Context Protocol) Server.

The RevSure MCP Server lets your team query your own RevSure go-to-market (GTM) attribution data through AI assistants such as Claude and ChatGPT. This document describes how the server authenticates users, isolates tenants, handles personal data, controls what the AI can do, and which third parties are involved. It is written to answer the questions security reviewers most often ask; where a control has a deliberate limitation, we state it plainly rather than imply more than the system does.

1. At a glance

2. Data processing summary

The MCP server exposes your own RevSure GTM (go-to-market) marketing and sales attribution data — sourced entirely from your own connected systems (CRM, marketing automation, enrichment vendors, web tracking). The standard data model has ~1,200 fields (your tenant may have additional custom fields on top of these, depending on your configuration); the large majority are non-personal business and analytics data (funnel-stage metrics, pipeline/opportunity amounts, campaign spend, attribution scores, aggregate journeys).

A subset is personal data (PII), limited to business/professional contact information (names, business email, phone, mailing/geographic location, job title/role, public social-profile URLs, online identifiers, and web-activity data). Data subjects are external B2B contacts/leads, website visitors, and your own internal users. No special-category data (GDPR Art. 9), government IDs, or financial-account numbers are intended to be processed.

"Does 'data types' in the review mean scopes?" No. "Data types" refers to the categories of data above. OAuth scopes are a separate, authentication concept (see §3) and in this integration convey identity, not per-dataset permissions.

➡️ For the full field-level breakdown, data subjects, special-category flags, and the PII masking controls, see the companion document: PII & Data Handling.

3. Authentication & credentials

3.1 Authentication mechanism

Every request to the MCP server must be authenticated. The server uses OAuth 2.0 with OpenID Connect (OIDC) through RevSure's identity system.

• Clients present a bearer JWT in the Authorization header.

• Tokens are JWT-signed with RS256 (asymmetric RSA/SHA-256). The signature is verified on every request against the identity provider's public keys, which are cached with a short TTL and refreshed automatically so revoked signing keys are detected quickly.

• The issuer, audience, expiration, and tenant identity claims are validated on every request.

• Access tokens are short-lived; refresh tokens enable long-lived assistant sessions and can be revoked independently at any time.

• All authorization-code flows use PKCE (S256), which is required by the identity provider — protecting against authorization-code interception.

3.2 Scopes and what the token covers

During authorization the server requests the standard OIDC scopes openid profile email offline_access. These are identity scopes (who the user is, plus a refresh token for offline_access) — they are not per-endpoint data permissions. What data a token can actually reach is governed by the user's own RevSure permissions (RBAC) and tenant, enforced by the RevSure backend (see §4). In other words: the token establishes identity; the platform enforces authorization.

3.3 Dynamic Client Registration (DCR) contract

The server implements RFC 7591 dynamic client registration, and MCP clients (Claude, ChatGPT) register automatically.

• Register URL: POST /{realm}/register (a global /register is also accepted; the realm is resolved from the request).

• Public clients / PKCE: the server returns "token_endpoint_auth_method": "none" — clients are treated as public PKCE clients. This is accepted and is the intended pattern for native/desktop clients.

• Response contains client_id only — never a client_secret. The backend client secret is injected server-side and is never exposed to the AI client (see §3.5).

• client_id format:

  • Auto-registered clients receive {realm}:{client_name}:{uuid} (e.g. Acme_Corp:claude-ai:0f9a…).

  • When a client is configured manually (e.g. ChatGPT's connector setup asks for an OAuth Client ID), use {realm}:{identifier}, e.g. Acme_Corp:claude or Acme_Corp:chatgpt. The requirement is simply that the value begins with your realm name followed by a colon.

• Grant types: authorization_code and refresh_token.

3.4 Endpoints & the non-interactive refresh flow (reissuing a bearer token)

Clients discover the OAuth endpoints automatically via RFC 8414 metadata at /.well-known/oauth-authorization-server. The advertised endpoints are:

• Authorization endpoint: /authorize

• Token endpoint: /token (the realm is resolved from the client_id, so the token endpoint itself is not realm-scoped)

• Registration endpoint: /{realm}/register/

• Supported: response_types=code; grant_types=authorization_code, refresh_token; token_endpoint_auth_methods=none, client_secret_post; code_challenge_methods=S256.

For a client that already holds a refresh token (e.g. a persistent assistant session):

• Endpoint: POST /token.

• Grant: grant_type=refresh_token with the refresh_token value; the client_id is your {realm}:… identifier.

• No client secret is required from the client — the server injects the backend credential itself.

• A fresh bearer (access) token is reissued, and a new refresh token may be returned. This is the supported path to keep a long-lived, non-interactive session authenticated without a new browser login. (A one-time interactive authorization_code login is required to bootstrap the first refresh token.)

3.5 Credential storage & rotation

• No credentials or API secrets are stored in application code or configuration files.

• Secrets live in a managed cloud secret store and are fetched at runtime under strict access controls. They are cached in memory only; nothing sensitive is persisted to disk by the application, and secrets are not written to shared caches.

• The backend client secret used for backend authentication is managed centrally in the identity provider, so rotating it propagates automatically (within a short cache TTL) with no redeployment and no per-tenant secret configuration.

• Client credentials for backend service authentication are never exposed to end users or AI clients — they are injected server-side transparently.

3.6 SSO / SAML / Microsoft Entra

SSO federation — including SAML and Microsoft Entra ID — is supported and configured per tenant in RevSure's identity provider. Because authentication is delegated to that identity provider, the MCP server validates the resulting token the same way regardless of how the user signed in (local credentials or federated SSO). Enterprises that require enforced SSO can have it configured for their realm.

4. Access controls & permissions

4.1 Read vs. write exposure

The overwhelming majority of tools are read-only analytics/attribution queries. A small, explicit set can write or take action:

All other tools — pipeline, funnel, campaign, journey, attribution, enrichment lookups, etc. — only read data. The LinkedIn actions are only possible after the user has personally connected and authenticated their own LinkedIn account via the connect link; RevSure acts strictly within the authorization the user granted. The config-edit and playbook tools operate only on the calling tenant's own RevSure configuration, and trigger_agent runs an agent the tenant has already configured.

Every tool has an explicit read/write scope. Each tool is published with standard MCP tool annotations that mark it as read-only or write, so a connected AI client can tell the two apart directly rather than inferring from the tool's name or description. The write scope is limited to exactly the tools listed above; read-only is the default, so every other tool is read-only. The write tools also carry finer-grained hints so the client has extra signal about each action before it runs:

• Most write tools are marked non-destructive — they only add data and never delete or overwrite (all four LinkedIn tools, remember_memory, reli_add_playbook, and trigger_agent).

• Two are marked destructive — reli_edit_icp_definitions and edit_additional_model_config can remove the specific configuration entries the user names (a targeted removal from the tenant's own config, not a bulk wipe).

• Tools that reach an external system are flagged with the external-system hint — the LinkedIn actions (the user's own connected LinkedIn account) and trigger_agent (an agent run can reach email/LinkedIn). The memory and config-edit tools operate only on RevSure's own data and are not flagged external.

"Does the integration require read, write, or both?" Both are technically present, but writes are narrow and user- or tenant-scoped: outreach from the user's own connected account, storing that user's own preferences, editing the tenant's own configuration, and starting an agent the tenant has configured. There is no ability to bulk-modify or bulk-delete your RevSure data through the MCP server.

4.2 Module-level permissions (RBAC)

The MCP server grants no permissions of its own. It calls the RevSure backend strictly as the authenticated user, passing only that user's identity and tenant — it does not add elevated roles or any module-override claims. Data access is therefore bounded by the user's existing RevSure permissions, enforced by the RevSure platform backend (the same authorization layer the RevSure web application uses).

"If a user has no access to a module (e.g. DGE), can they use the corresponding MCP tools?" They may invoke the tool, but they only ever receive data their RevSure permissions already allow — the backend applies the user's existing access, so a request for data the user cannot see in the product returns no such data through the MCP server either. The MCP layer adds no access a user doesn't already have. Additionally, specific features can be enabled/disabled per tenant (for example, the memory feature can be turned off on request).

4.3 Write-tool risk & human-in-the-loop

We treat mutation tools conservatively:

• Blast radius is limited. Writes are confined to: LinkedIn outreach from the user's own connected account, per-user memory, edits to the tenant's own RevSure configuration (Reli ICP definitions, Reli playbooks, and attribution-model / Projection settings), and starting an agent run the tenant has configured. Two config-edit tools can remove specific user-named entries, but there is no bulk-mutation or bulk-delete path — no tool can wipe or mass-modify your RevSure data.

• Agent runs are gated by a tenant-admin allowlist — a control RevSure does enforce server-side. trigger_agent can only start agents an admin has explicitly enabled for MCP use (Reli config → Integration Settings). A request to run any agent not on that list is rejected before it starts. So a tenant that does not want agents capable of writing to external systems (e.g. a CRM-writing agent) simply leaves them off the allowlist, and they cannot be invoked through the MCP server at all.

• The tool descriptions instruct the assistant to confirm the action with the user before any LinkedIn send (recipient and message content) and before starting an agent run that can act externally. However, whether that confirmation is actually surfaced depends entirely on the AI client — it is not something RevSure can enforce.

• Because the major MCP clients do not currently support the protocol's elicitation (human-in-the-loop) capability, we do not implement a server-side approval prompt today.

• Write actions are flagged with standard MCP annotations. Each write tool carries a machine-readable "not read-only" marker (plus the non-destructive/destructive and, for the LinkedIn actions and trigger_agent, external-system hints noted above), so a compliant AI client can recognize an action tool and prompt the user before it runs. Like the tool descriptions, this is an advisory signal the client chooses to honor — not a gate RevSure enforces server-side.

4.4 Tenant isolation

• Each organization is a separate identity realm; credentials and sessions from one tenant are never valid for another.

• The tenant identity is taken from the cryptographically validated token, never from request parameters, tool arguments, or prompt text — so there is no way to reach another organization's data by manipulating input.

• Requests are routed to the tenant's own backend, and the backend independently enforces tenant scoping. There is no cross-tenant "superuser" path.

Realm routing cannot be abused to obtain another tenant's token. At the token endpoint the tenant is derived from the client_id prefix, but this is only a routing label — it decides which realm's identity provider the request is forwarded to; it grants nothing on its own. To receive a token you must present a credential the identity provider issued for that realm (an authorization code from an interactive login against that realm, or a refresh token previously issued by it). A credential from one realm is invalid in another, and PKCE binds each code exchange to the client that initiated it. As an independent backstop, every MCP request re-validates the token's signature and issuer against the realm in the request URL — so a token is bound to its realm both when issued and when used. Putting a different realm name in a client_id can only cause your own request to fail; it cannot mint or fetch anyone else's token.

5. PII masking

RevSure provides a tenant-configurable privacy control (Config Center → Reli Config → Privacy) that, when enabled, redacts contact/lead/visitor/internal-user names and email addresses (and PII-classified fields) to ***. Crucially, masking is applied server-side, inside the MCP server, before the tool result reaches the AI assistant — the AI model never receives the raw values. It is a data-minimization control, not a claim that every personal field is redacted; access to all data is otherwise governed by authentication, RBAC, and tenant isolation (§3–§4).

➡️ Full detail on the masking behavior, exactly which fields are and aren't covered, and how to configure it lives in the companion document: PII & Data Handling.

6. Where your data goes: AI providers & third-party sub-processors

6.1 Does RevSure send data to Anthropic or OpenAI?

The MCP server does not itself transmit data to Anthropic or OpenAI. However, the MCP model is that you connect your own AI assistant (Claude, ChatGPT, etc.). When you ask that assistant a question, it calls RevSure tools and the results are returned to that assistant — so the data you request is processed by the AI provider you have chosen and connected, under your agreement with that provider. This is inherent to using an AI assistant and is within your control (including which assistant you connect and under what terms). Data processed by any AI assistant you connect, or by the sub-processors below, is governed by those providers' terms.

6.2 Google (for RevSure-side AI features)

Two RevSure features use Google's AI:

• Semantic dimension search uses Google Vertex AI running inside RevSure's own Google Cloud project and region to turn a short search phrase into a vector. The text stays within RevSure's cloud tenancy.

• Memory (optional; see §7) uses the Google Gemini API to extract and embed the short facts a user asks to remember. This sends that fact text and recall queries to Google's Gemini API. Memory can be disabled for your tenant on request.

6.3 Third-party data providers (sub-processors)

RevSure uses the following external providers to enrich and resolve GTM data. Each call is a single-entity lookup — the specific email or company domain in question is sent, not a bulk export of your dataset.

Data minimization: enrichment lookups are single-entity — the email/domain being researched is sent, one lookup at a time. Authentication distinction: of all the above, only Unipile operates using the user's own connected credentials — every other provider is called under RevSure's service credentials.

6.4 Network exposure

Only the authenticated, TLS-protected MCP endpoint is reachable from the internet. RevSure's internal supporting services (databases, caches, configuration, and backend services) are not exposed to the public internet.

7. Memory, prompt injection & OWASP considerations

7.1 How memory works

The optional memory feature lets the assistant remember a user's stated preferences and context across sessions.

• Scope: every memory is stored and retrieved under a key derived from tenant_id + user_id, both taken from the validated OAuth token — so a user's memories are isolated to that user within that tenant. Memory operations refuse to run unless the caller is an identified end user.

• No cross-tenant leakage: because the scope comes from the cryptographic token (not from anything the model or a prompt can set), one tenant's or user's memory cannot be read or written by another.

• Retrieval is explicit and treated as data, not instructions: a small set of first-tier memories may be loaded at session start, and others are fetched only when the assistant explicitly calls the recall tool. In both cases the memory text is explicitly framed to the model as user-supplied data, not instructions that override the current request — mitigating memory-poisoning (OWASP MCP05) concerns.

• What is stored: the fact-extraction step is instructed to store only short GTM-relevant preferences. Memory can be disabled per tenant on request.

7.2 Tool descriptions do not contain hidden instructions

Tool descriptions are functional documentation — what the tool does and what its parameters mean. They do not contain hidden or adversarial "instruction injection" directives.

7.3 Can an adversarial prompt trigger cross-tenant access?

No. The user's tenant and identity are derived from the cryptographically validated OAuth token, never from prompt content or tool arguments. No prompt can change which tenant or user a request runs as, and sensitive/write operations additionally require an identified end-user identity. The backend independently enforces tenant scoping on every call.

8. Audit logging

What is logged (to internal, access-controlled logs):

• User identity (realm, tenant, user ID), tool name, timestamp, duration, and success/error status for every authenticated request.

• Access & security events — authentication failures and anomalous access are logged at elevated severity.

• Tool request arguments, retained for debugging and support. These can include business identifiers (for example, an email used as a lookup value). Logs are internal and access-controlled, not customer-exposed.

What is deliberately not logged:

• Full token payloads are never written to logs by default. Debug logging of sensitive fields requires an explicit opt-in and is intended only for controlled development environments.

• On success, tool response bodies are not logged — only a lightweight fingerprint (result type and item count). Fuller detail is captured only on errors, to make failures debuggable without reproduction.

9. Architecture, transport & reliability

• This is a native MCP server, not a workflow/Zapier-style ("Zapflow") integration. It speaks the MCP protocol over authenticated HTTPS and is designed for interactive AI assistants (Claude, ChatGPT) and any standards-compliant, OAuth-authenticated MCP client. Every consumption mode requires the same per-user OAuth authentication described in §3.

• Transport security: all communication between AI clients and the server is encrypted over HTTPS/TLS. No sensitive data travels in URLs or query strings — credentials and tokens travel only in request headers.

• Encryption at rest: data at rest is encrypted by the underlying managed cloud platform.

• Data residency: customer data is processed and stored in the region matching your deployment (e.g. US or EU).

• Stateless & horizontally scalable: the server runs statelessly, so it scales horizontally behind a standard load balancer with no sticky sessions.

• Availability & SLA: the MCP Server is Generally Available (GA) and publicly usable in production, backed by a 99.9% uptime SLA.

10. Compliance posture

The server is built on open standards that align with common enterprise compliance requirements:

Security incidents: RevSure has had no reportable security incidents to date.

11. RevSure Trust Center

• RevSure Website: https://revsure.ai/

• Security & Compliance: https://security.revsure.ai/

• Privacy Policy: https://www.revsure.ai/privacy/policy

• Terms and Conditions: https://www.revsure.ai/terms-and-conditions

This document describes the RevSure MCP Server as currently implemented. For questions not covered here, contact RevSure team.

Does RevSure MCP protect against prompt injection attacks?

RevSure's MCP environment is designed with a significantly narrower attack surface than general-purpose MCP implementations. While we do not currently publish a dedicated prompt injection security specification, several architectural controls help mitigate the risk and impact of adversarial inputs.

Can unauthenticated users access MCP tools or data?

No. All MCP requests require authentication using a valid Keycloak-issued JWT. Unauthenticated users cannot invoke tools, access memory functions, or retrieve customer data.

Can external attackers manipulate MCP responses?

The risk is substantially reduced because MCP access is restricted to authenticated users. Attack scenarios that rely on anonymous access or unauthorized tool execution are not applicable within RevSure's MCP environment.

Does RevSure MCP process arbitrary web content or other untrusted external data?

No. MCP tools operate on data sourced from RevSure's analytics platform rather than arbitrary content from the internet, emails, websites, or other external sources. This significantly reduces exposure to common indirect prompt injection techniques.

What happens if adversarial or misleading text exists within customer data?

If adversarial content were present in customer-managed data fields (such as CRM opportunity names or campaign names), it could potentially influence the analytical response generated for an authenticated user within the same tenant. However, the impact is limited to the analysis presented to that user.

Can MCP tools modify data or perform actions outside the platform?

No. RevSure MCP tools are read-only. They do not modify records, execute external actions, transmit data to third-party systems, or perform operations that affect customer data.

Could a prompt injection attack expose data from another customer?

No. MCP tools operate within the authenticated tenant context and enforce tenant isolation. The platform does not provide mechanisms for accessing data across customer environments.

What is the maximum potential impact of a prompt injection attempt?

Because the MCP toolset is read-only and tenant-scoped, the maximum impact is limited to potentially influencing the analytical output shown to an authenticated user within their own tenant. Prompt injection cannot trigger external actions, modify source data, or access information belonging to other customers.