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 — and writes are OFF by default

The server is read-mostly: 40 of 54 tools only read. Beyond that, every organization starts with MCP writes disabled, including existing paid ones. Until an org admin turns them on at Settings → Organization → AI agent access, a connector can analyze everything and change nothing.

An interactive connector’s token always carries both scopes — Cognito has no per-scope consent toggle, so admin:write is issued to every connector user including a viewer. That is precisely why the scope is not what protects a write.

A cak_ service key is a genuinely read-only credential: it is minted with the read scope alone and cannot hold admin:write, so it is refused at the first check regardless of the organization switch. See Authentication & authorization.

Writes are gated four ways, server-side

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

1. the access token carries admin:write;
2. the organization has enabled MCP writes (default: off);
3. your org role is admin or super_admin; and
4. the call includes confirm: true.

If CloudQuell cannot read the organization’s switch or your role, the write is refused, not attempted — the gate fails closed.

This is stronger than a client-side allow/deny prompt: a compromised or over-eager client cannot mutate anything unless the organization has deliberately opted in and the signed-in human is an admin. And an agent cannot opt the organization in for itself — update_organization_preferences refuses to set that preference, so only a human admin in the app can.

MCP annotations (destructiveHint, etc.) are advisory UI hints — they never gate behavior. admin:write does not elevate your CloudQuell role: admin-only actions are still authorized by the backend against your role as well.

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.
• Leave the organization write switch OFF unless you need it. It is off by default and that is the right setting for most organizations — especially any whose agents also process untrusted input. Turn it on deliberately, and turn it back off when the work that needed it is done.
• Use a cak_ key for anything headless. Those are read-only by construction, so a scheduled agent cannot change anything even if the organization switch is on.
• 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.