Permissions, privacy, and security

What Survicate MCP can reach on your behalf, where your data goes, and how the server is secured.

Access and privacy

• It acts as you, and only as you. Every request runs with your Survicate permissions. If you cannot open a folder in Survicate, the assistant cannot see the surveys in it. If your Research Hub role is read-only, the assistant cannot save notes or start projects for you.
• One workspace per connection. You choose the workspace when you approve, and the connection stays bound to it. To work with another workspace, add a separate connection for it.
• No API keys. You sign in to Survicate and approve on a Survicate screen. Nothing is pasted into the assistant.
• Access follows your account. If you leave the workspace or your account is blocked, the connection stops working within an hour. Changing your password, email, or two-factor setting also ends the connection, and you simply approve it again. For safety, every connection asks for re-approval after 90 days, or sooner if it goes unused for 30 days.
• Disconnect any time. Remove Survicate in your assistant's connector or plugin settings. In Claude that is Customize, then Connectors, then Connected; in ChatGPT it is Customize, then Plugins, then Uninstall.
• Regulated workspaces stay out. Workspaces flagged as HIPAA-regulated cannot be connected to AI assistants.
• Your data goes to the assistant you chose. Survicate does not filter or redact what the assistant asks for. It receives the same data you would see in the panel, which can include personal details a respondent typed into an answer. What the assistant's provider does with that data is governed by your agreement with them, so check your company's policy before connecting.
• Admin controls. Survicate does not yet offer a switch to stop members from connecting. Most assistants let an administrator decide which connectors are available, so use that to manage access for now.

How the server is secured

Survicate builds and runs the MCP server itself. These details are for security and IT teams reviewing it.

Authentication and tokens

Every remote connection uses OAuth 2.1 over TLS.

• PKCE with S256 only. The plain method is rejected.
• Dynamic client registration (RFC 7591).
• Resource indicators (RFC 8707), so a token issued for another resource does not work here.
• Short-lived tokens. Access tokens last at most an hour. Refresh tokens rotate on every use, expire after 30 days without use, and in any case 90 days after approval.
• Hashed at rest. Access tokens, refresh tokens, and authorization codes are stored as SHA-512 hashes, never in plain text.
• Scopes enforced on the server. Tools that change data require the mcp scope, and a token without it is refused.

Your assistant's token is checked when a request arrives and goes no further. It is never forwarded to other services; internal calls use separate service credentials. Your survey permissions are checked on every call rather than fixed at approval, so changes to your access apply straight away. If the service that resolves your permissions cannot be reached, the call is refused rather than answered with unfiltered data.

Infrastructure and secrets

The server runs in a private network on AWS, reachable from the internet only through its public endpoint, under its own service identity with no human account behind it. Traffic between Survicate services stays inside that network.

Secrets and service credentials live in a managed secrets store and are never kept in source code, configuration files, or logs. The assistant cannot reach them: tools return survey and feedback data only.

Each release is built from Survicate's own source and deployed as a container image with a unique tag. The running service points at that exact image, so nothing updates underneath it.

What the tools can do

The tool set is fixed and listed in the technical overview. Most tools only read data, and every tool is limited to the connected workspace and to the surveys you can already see. The server never calls into your own systems. Tools that change data are described so that your assistant asks you to confirm first; that step belongs to the assistant, and the server does not enforce it. What the server does enforce is the mcp scope: a token without it cannot change anything.

No tool can send an email, call a webhook, publish, or share anything outside Survicate. Even if a prompt injection succeeded in steering the assistant, it would have no way to move data out through Survicate MCP.

Logging

Every tool call is logged with the tool, workspace, user, credential and client, outcome, and duration. The authorization server logs sign-ins, approvals, token issuance, and revocations. These operational logs record no question or answer text; the AI observability data described under Where data goes is separate.

Logs are kept in AWS CloudWatch for at least two years and forwarded to Datadog.

Where data goes

Survey data reaches the assistant you connected, as described above. Survicate also uses Braintrust for AI observability. It receives prompts and responses, which can include survey answers, and is covered by Survicate's DPA as a subprocessor.

Security reviews

All tool descriptions, the values inserted into them, the input schemas, and the server instructions have been reviewed for embedded instructions and prompt injection risk. Values a customer controls, such as the workspace name, are escaped before they reach the assistant.

The server is also tested against a full security audit covering access control and tenant isolation, prompt injection, input validation, information disclosure, authentication, and destructive writes, on every tool and on the internal services behind them. Tenant isolation passed every scenario tested. To discuss the methodology, email security@survicate.com.