Your Data. Protected.

Cresva operates a Model Context Protocol server at https://cresva.ai/mcp. A user may connect a third party AI assistant, such as Claude, ChatGPT or Cursor, to that server. The assistant is the client: it authenticates to Cresva using OAuth 2.1 and holds its own access token.

A connection can read only the brands the user selected on the Cresva consent screen at the time of granting, and only through the tools that the granted scopes permit. It cannot enumerate or reach an account the user did not grant, and it cannot reach another customer's data.

The connector is read only by default. Of the tools the server registers, all but one are reads. The single tool that is not a read opens a price negotiation on the customer's own storefront, and it requires a scope that is off unless the user turns it on when granting.

A connection is granted by an individual user and carries that user's identity. Anything the assistant reads is what that user is entitled to read, and their permissions are re-evaluated at the time of each call rather than frozen when the grant was made. A user who loses access to a brand loses it through the connector at the same moment.

Every tool call is written to Cresva's audit log against the granting user, the assistant that made it and the grant it was made under. An administrator can therefore attribute any connector activity to a named person. Audit records are retained on the same schedule as other account audit data.

When a connected assistant calls a tool, Cresva returns the answer to that tool call to the assistant, over TLS. Nothing else is transmitted: Cresva does not send the assistant vendor credentials, connected platform tokens, other customers' data, or any bulk export of the customer's account.

Once an answer reaches the assistant it is governed by the agreement between the user and that assistant's vendor. Cresva has no visibility into, and makes no representation about, how a vendor stores, processes or trains on content the user brings into their own conversation. A customer evaluating that risk should read the vendor's terms.

Cresva stores, for each connection: the registered client, the granting user, the brands and scopes granted, the time of grant, and the time the connection was last used. Access tokens and refresh tokens are stored as hashes rather than in a recoverable form.

Access tokens are short lived. Refresh tokens are single use: a refresh issues a new refresh token and invalidates the one presented, and presenting a token that has already been used revokes the grant. Records of a revoked grant are retained as audit history rather than deleted, so that past access remains attributable.

A user can revoke a connection at any time from Connected apps in their Cresva settings. Revocation takes effect immediately: the tokens are invalidated and the next call from that assistant is refused. Revoking one user's connection does not affect any other user's.

Removing a user from the Cresva account, or removing their access to a brand, has the same effect on what their connections can reach, because permissions are evaluated per call.

Cresva issues test API keys, distinguishable by their sk_test_ prefix, alongside live keys. A request authenticated with a test key reads simulated data only. It does not read the customer's connected accounts and cannot change any record. Test keys exist so that an integration can be built and run in a customer's own CI without touching production data.