Skip to main content
Rippit sits on both sides of MCP, and the two directions have different security properties. This page covers each in turn. For Rippit’s company-wide security posture (certifications, subprocessors, encryption, penetration testing, and requestable reports), see the Rippit Trust Center.

​
Rippit as an MCP server

How your AI assistant authenticates to Rippit and what it can reach once connected. This applies to every client under Connect your client.

​
How authentication works

The Rippit MCP server is an OAuth 2.1 Protected Resource (RFC 9728). Your client bounces you to app.rippit.com in a browser window, you sign in there, and your client receives a short-lived JWT audience-bound to this MCP server (RFC 8707). You only ever enter your Rippit credentials in the browser. The MCP server and your assistant never see them. Supported clients refresh tokens automatically; if a token cannot be refreshed, you will be prompted to sign in again.

​
Client registration

Some clients are registered with Rippit in advance, such as Claude and Gemini Enterprise. Others identify themselves at first use through OAuth 2.1 dynamic client registration (RFC 7591), which is what lets any MCP client connect without Rippit pre-provisioning it. Registering a client grants no access to anything. It establishes an identity, and nothing more:
  • PKCE is mandatory for every client, registered in advance or not.
  • Scope is capped to mcp (plus offline_access when a refresh token is requested). A client that asks for more does not receive more.
  • Registration is held for one hour and discarded unless a real user completes sign-in and consent. An unused registration expires having accessed nothing.
  • Registration is rate-limited per source and globally, and individual registered clients can be revoked.
  • The consent screen marks these clients unverified, with their name and redirect address labeled as self-reported, because Rippit is taking the client’s word for both.
Everything after registration is identical for every client: the same user authentication, the same audience-bound token, the same permission checks on every request.

​
Token scope

The MCP server acts as the signed-in user. It can read and write only what that user could read and write directly in app.rippit.com. There is no service account, no admin scope, and no way for the MCP server to bypass Rippit’s existing workspace permissions or role assignments. Every request is re-checked against the user’s current permissions; the token itself grants nothing beyond identity. Revoking a user’s access in Rippit revokes their MCP access on the next token refresh.

​
What your assistant can access

Your assistant can read two kinds of data through the connector:
  1. Tables and worksheets. It gets only the columns defined on the table it’s querying.
  2. Conversations. When it opens a conversation the user is allowed to see, it gets the full message transcript plus the ticket’s stored fields (tags, custom fields, AI classifier values, and so on). If customer names, emails, or other PII are captured in ticket fields or mentioned in the transcript, your assistant can see them.
Removing a column from a worksheet hides it from table reads, but it does not hide the underlying value from conversation reads. If a value is stored on the ticket, your assistant can see it when it opens that conversation.
Conversation access follows the same rules as the Rippit app, checked on every request. Access is all-or-nothing per conversation. If the user can open it in Rippit, your assistant gets the full record; if not, it gets nothing.

​
Input and output checks

Every request to the MCP server is checked before it runs: it must match a strict, predefined format (valid IDs, approved filter types, length limits), and anything that doesn’t match is rejected outright. Requests are also rate-limited per user. On the way out, responses are checked against a predefined format too (anything unexpected is blocked rather than passed through), and results are size-capped. AI-generated values are constrained to specific allowed types (like a fixed list of categories), so the model can’t return free-form content where structured data is expected.

​
Hostnames and transport

For allowlisting, the client touches three origins:
app.rippit.com is reached by both the browser and the client itself: the browser for user sign-in, the client directly for registration and token exchange. Egress rules that allow only browser traffic to app.rippit.com will break authentication.
All traffic is HTTPS only, TLS 1.2 or newer (TLS 1.3 preferred; older protocols are rejected). No client-side traffic goes to third parties.

​
Card sandbox

In clients that support MCP UI cards, Ask Rippit cards render inside the client’s standard sandboxed iframe. The card’s only outbound network capabilities are JSON-RPC calls back to mcp.rippit.com (proxied through the host) and static asset loads from cdn.rippit.com.

​
Rippit as an MCP client

How Rippit’s own agent connects out to MCP servers you choose, and how those credentials are handled. This applies only if someone in your organization has connected a server under Rippit Agentic Chat.

​
Who can connect a server

A Rippit Full Admin. Connections are made once and are then available to agent runs, so this is a deliberately narrow permission.

​
Whose access a connection carries

Most MCP providers only support user-delegated OAuth, so a connection acts as the person who authorized it.
Sharing a connection organization-wide does not merge permissions. It gives everyone in your Rippit organization, plus scheduled runs, the agent’s access to the authorizing person’s account, including private content. Any write tool that is enabled acts as that person.
Rippit requires an explicit acknowledgment of this before an organization-wide connection is saved. Where a provider supports an application token instead, such as Intercom, that avoids attaching one person’s identity to shared use.

​
Credential handling

  • Credentials are encrypted at rest with AES-256-GCM. Only the Rippit web application holds the key; the agent runtimes never decrypt anything and never read the stored connections.
  • Each agent run receives a short-lived, run-scoped set of resolved credentials that expires within minutes and is never persisted or logged by the runtime.
  • Credentials are never shown again after they are saved. Rotating one means reconnecting.
  • Disconnecting deletes the connection and its stored credentials.

​
Tool permissions

  • Connections start read-only. Rippit enables only the tools the provider’s server declares read-only.
  • Enabling a write tool is explicit, per tool, and applies to every run using that connection.
  • The agent can call only tools that are currently selected. A tool the provider adds later is not available until an admin refreshes the tool list, and is never called silently.

​
Network controls

  • Connections must use HTTPS and the Streamable HTTP transport.
  • Outbound requests are checked against a server-side address filter, so servers on private or internal address ranges are refused. Rippit connects only to publicly reachable endpoints.
  • Response sizes and connection deadlines are capped.

​
What leaves Rippit

Whatever the agent sends to a connected server as tool arguments, which for an analysis workflow typically includes conversation content, summaries, and findings. Treat a connected server the way you would treat any system you export conversation data to, and scope its credential accordingly.

​
Both directions

​
Data handling

Rippit retains tool-call telemetry (which user, which tool, when, with what argument shape) for support and abuse prevention. Rippit does not train any AI models. Your data is used for inference only. For Google Drive connections, Workspace data is used only to provide the user-requested chat, Skill, or Action and may be sent to the model provider configured for that feature. Rippit does not use Google Workspace data to train or improve generalized AI or ML models. Drive file content and base64 downloads are request-scoped and are not retained in durable chat tool-result previews. Rippit’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. Drive handling also follows the Google Workspace API user data developer policy. Once data reaches your assistant, how it is handled is governed by your agreement with that assistant’s vendor, not by Rippit. In practice:
  • Claude for Work: covered by your commercial agreement with Anthropic; Anthropic does not train on commercial (Claude for Work / API) data by default.
  • ChatGPT Business, Enterprise, and Edu: covered by your agreement with OpenAI.
  • Other clients: check the vendor’s terms for the plan you’re on.
If users connect from personal accounts rather than an organization-managed workspace, training and retention behavior depends on each user’s own account settings. We recommend deploying the connector through a business or enterprise workspace so your organization’s terms apply.
For retention windows, deletion, processing locations, and subprocessors on the Rippit side, refer to your Rippit DPA.

​
Is this agentic AI?

It depends which direction you mean. The MCP server is not an agent. It’s a permissioned set of tools that your assistant, running under your agreement with its vendor, can call. Rippit provides no model and takes no action on its own. Rippit Agentic Chat is an agent. It plans, queries data, calls tools, and iterates in a multi-step loop, using a model Rippit provides. It acts only within the permissions of the signed-in user and the connections an admin has authorized, and it can reach an external system only through a tool that is currently enabled on a connection.