Security & privacy

How the CloudQuell MCP server protects your data and limits what an agent can do.

Prompts are not stored by CloudQuell

The server processes each MCP request and returns data — it does not store your prompts or the model’s responses. Your conversation lives in your MCP client (Claude, Cursor, etc.) and with that client’s model provider, governed by their privacy terms. CloudQuell sees only the tool calls your agent makes (e.g. get_savings with a filter) and returns the corresponding data, plus standard operational logs (see Audit logging).

Read-only by default

The server is read-mostly: 29 of 43 tools are read-only. A connection made with the default read scope can analyze everything and change nothing — every write tool refuses before any backend call. You opt into writes explicitly by granting the admin:write scope at sign-in. See Authentication & authorization.

Writes are double-gated, server-side

A mutation happens only when both are true, checked inside CloudQuell before any downstream call:

1. the access token carries admin:write, and
2. the call includes confirm: true.

This is stronger than a client-side allow/deny prompt: a compromised or over-eager client still cannot mutate without the scope and an explicit confirmed argument. MCP annotations (destructiveHint, etc.) are advisory UI hints — they never gate behavior. And admin:write does not elevate your CloudQuell role: admin-only actions are still authorized by the backend against your role.

Scoped, short-lived tokens

• OAuth 2.1 + PKCE (S256) with a public client (no shared secret to leak).
• Access tokens are short-lived (~1 hour); a refresh token renews them without re-prompting and can be revoked.
• Audience binding (RFC 8707): tokens are minted for this server’s resource URI (https://mcp.cloudquell.com/mcp) and the server rejects tokens issued for anything else — the confused-deputy defense.
• The server validates every token’s signature (Cognito JWKS), issuer, audience, and scope on each request, then forwards a token that identifies only you to the backend, which re-validates it and resolves your org/role from the database.

Tenant isolation

The agent is locked to your organization. Identity is derived from your token’s sub and mapped to your org membership server-side — it is not a parameter the client or agent can set. There is no path to another tenant’s data.

Audit logging

Tool invocations flow through the gateway and Lambda with standard request logging, and mutations hit audited CloudQuell backend routes (the same routes the dashboard uses), tied to your identity. If you need a specific audit trail for agent activity in your org, contact CloudQuell support.

Prompt-injection caution

The dominant risk for any agent with data access is the “lethal trifecta”: access to private data + exposure to untrusted content + an exfiltration path. Practical guidance:

• Be wary of untrusted content in context. If your agent also browses the web, reads tickets, or ingests third-party documents in the same session, a malicious instruction there could try to coax it into calling tools. The default read-only posture limits the blast radius to reading your own cost data.
• Keep admin:write off unless you need it. Don’t grant write scope to an agent that also processes untrusted input. Use a separate, read-only connection for general analysis.
• Rely on the confirm gate. No write is a silent side effect — review what the agent says it will change before confirming.
• Treat tool output as data, not instructions. Cost data returned by a tool should never be acted on as if it were a command.

Reporting a security issue

Found a vulnerability? Contact CloudQuell security/support rather than filing it in a public issue tracker. Do not include live tokens or secrets in reports.