Privacy Policy

Last updated: September 21, 2026

1. What this notice covers

This notice applies to the Cakewalk MCP Test Kitchen only:

· the landing page at mcp-test-kitchen.cakewalk.security

· the console you sign in to, at /login and /console

· the MCP endpoint at mcp-test-kitchen.cakewalk.security/mcp

· the reference test client

It does not cover the Cakewalk website at cakewalk.security or the Cakewalk platform at app.getcakewalk.io. Those are covered by the Cakewalk Privacy Policy. This notice is published on the Cakewalk website for convenience, which does not extend it to that site. Where that notice and this one differ, this one governs for the Test Kitchen.

2. Who is responsible

The controller for the processing described here is:

Cakewalk Technology GmbH Hardenbergstraße 32, 10623 Berlin, Germany Registered at Amtsgericht Charlottenburg, HRB 229577 B Managing Directors: Gil Röder, Dr. Johannes Keienburg

Privacy questions and requests: privacy@getcakewalk.io

3. What the Test Kitchen is, and what that means for your data

The Test Kitchen is a hosted MCP server that misbehaves on purpose. You point an MCP client you already have at our endpoint, and we return faults at the HTTP transport, in the JSON-RPC envelope and inside the tool result, so you can see how your client handles them.

To do that, the server sits in the middle of your client's traffic and records it. Three consequences you should understand before you connect:

We record metadata about every request, and a summary of its parameters. We do not store response bodies, and we do not store the arguments you pass to a tool call. What we do keep is described precisely in §4.3.

Your traffic is attributable to you. You sign in, we mint a token, and requests carrying that token are linked to the account that generated it. That is how the server knows which scenario to run for you. It is not anonymous.

This is a sandbox, not production infrastructure. Do not send personal data, customer data, production data, credentials or anything confidential through it. Use synthetic data. Our Terms of Service at https://www.cakewalk.security/mcp-test-kitchen/legal/terms say the same thing, and it is the single most important line in either document.

That last point is not boilerplate. Parameters we do keep are kept in full when they are small. A secret placed in a request body, rather than in the Authorization header which we always redact, would be recorded.

4. What we collect

4.1 Sign-in identity

When you sign in we receive your email address and nothing else. We request only the userinfo.email scope from Google and the user:email scope from GitHub. We do not receive or store your name, your profile picture, or your provider account ID, and we do not store the access or refresh tokens the provider issues. Those are discarded after sign-in.

Both Google and GitHub sign-in are available.

We use your email address to sign you in, and to contact you about the Test Kitchen itself. We do not use it for marketing, we do not add it to a mailing list, and we do not give it to anyone else.

4.2 Your MCP access token

We generate and store one personal access token per account so you can authenticate your client. It is stored as a hash for lookup, plus an encrypted copy so the console can show it to you again. You can regenerate it at any time, which immediately invalidates the previous one.

To be explicit about what the token does not have, since these are the first questions a security reviewer asks: it carries no scopes, has no expiry, is not rotated on any schedule, and we do not record when it was last used. Regenerating it, or deleting your data under §8, is the only way to invalidate it.

4.3 Observation records

For each MCP request that reaches the server we record:

· the JSON-RPC method

· the phase and the HTTP status

· the duration

· the protocol revision your client declared

· which scenario was active

· whether the request was cancelled

· a summary of the request parameters, described below

· the header map, redacted as described in §4.4

· an internal request trace identifier

· the email address you signed in with

How parameters are summarized. This is deliberately narrow:

· On a tool call, we keep the tool's name and discard the arguments entirely.

· On connection, we keep the protocol version and your client's name and version.

· For any other method, we keep the parameters only if the raw JSON is 512 characters or fewer. Anything larger is discarded rather than truncated. This is the one case where something you sent is stored verbatim, so a resource URI or a prompt argument does land in the record.

We never store response bodies, including the fault payloads the server itself generates.

Requests that fail authentication are also recorded. The server writes the observation before it validates your token, so a request with a missing, malformed or invalidated token still produces a record, but with no account attached to it. Two consequences worth stating plainly:

· Nobody can see those records in the console, including you, because the console only shows records attributed to an account. If your client reports a 401 and your pane stays empty, that is expected.

· Because they carry no account, the ERASE EVERYTHING button in §8 does not remove them. They are deleted by the seven-day rule in §6 like everything else.

4.4 Request headers

We keep six header values by allowlist: accept, content-type, content-length, host, user-agent and mcp-protocol-version. Every other header value is replaced with [redacted].

Two clarifications that matter:

· Header names are kept; header values are not. The record therefore shows that your client sent an Authorization header, or any custom header, without its value.

· The value of your Authorization header is never recorded. We have verified this holds on the success path, the error path, the cancellation path and the malformed-request path. We state it about that header specifically, not about tokens in general. See the closing paragraph of §3.

4.5 Technical data

IP addresses. The application does not store your IP address. It is used in memory only, to partition rate limiting.

Our hosting provider necessarily sees the IP addresses of incoming connections at its edge. Fly.io publishes a seven-day retention period for the app log search it offers, and says that keeping logs beyond that requires shipping them to an external service. We run no log shipper, so nothing from the edge reaches us or is retained by us.

User agents. Your client's user-agent header is on the allowlist in §4.4 and is stored with the record.

Cookies and browser storage. The console sets one authentication cookie. It is HttpOnly, SameSite=Lax, Secure, and scoped to the console's own host. No cookie domain is set, so nothing is shared with or inherited from cakewalk.security. The console also stores two interface preferences in your browser's local storage, your color theme and a panel width, and one session flag recording that it has already shown you your access token. None of that leaves your browser or reaches us.

Because the only cookie is strictly necessary for authentication and no analytics or marketing cookies are set or inherited, no consent banner is required.

Analytics and error tracking: none. There is no analytics, no application performance monitoring, no error tracking, no session recording and no third-party script on any page of this product.

4.6 Feedback submissions

The console has a feedback box. What you type in it is sent to Cakewalk engineering by email, with your account email address set as the reply-to address, so the submission is linked to you. It is not stored in our database at all.

Because it is delivered as email, a feedback submission sits outside the seven-day retention in §6 and is not removed by the ERASE EVERYTHING button in §8. It persists in our mail provider and in an engineering inbox. Our mail provider keeps the message for about 30 days, stores it in the United States, and keeps its own backups for a further 7 days.

We keep feedback for as long as we need it to answer you and improve the tool.

A submission is limited to 2,000 characters, and that limit is enforced by the server, not only by the interface.

5. Why we process it, and on what legal basis

We do not use your sign-in email for marketing. We do not sell your data, and we do not use it for advertising or profiling.

We do not run product analytics on your use of the service. There is one internal operational view showing how many accounts exist and how many observations each has recorded, with email addresses masked to their domain only. It does not expose the content of anyone's records.

6. How long we keep it

7. Who else touches your data

· Google, for sign-in, userinfo.email scope only. Our counterparty is Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland, registration number 368047.

· GitHub, for sign-in, user:email scope only.

· Fly.io, for hosting and managed PostgreSQL. Fly.io, Inc. is incorporated in the United States; the service and its database are deployed in Amsterdam.

· Resend, the provider that delivers feedback submissions by email. The contracting entity is Plus Five Five, Inc., San Francisco, California, trading as Resend.

That is the complete list of external services this product talks to. Each of them engages its own sub-processors, which is ordinary and is governed by our agreement with them rather than enumerated here. Fly.io publishes its list at https://fly.io/legal/sub-processors/ and it is worth reading if you care where infrastructure logs go: it names third parties used for tracing, observability and AI-assisted log analysis.

We may also disclose data where we are legally required to, or to establish, exercise or defend legal claims.

International transfers

The service and the database that holds your records run in the European Union, in Fly.io's Amsterdam region. This is consistent with the "data stored in Europe only" statement published for the Cakewalk platform.

Our hosting provider and our email provider are both US-incorporated companies, so administrative access from outside the EU cannot be ruled out by deployment region alone. Where such access occurs, these are the safeguards it relies on:

· Fly.io, Inc. is certified under the EU-U.S. Data Privacy Framework, including the UK Extension and the Swiss-U.S. Data Privacy Framework, and additionally makes a pre-signed Data Processing Agreement incorporating Standard Contractual Clauses available to customers.

· Plus Five Five, Inc. (Resend) is certified under the EU-U.S. Data Privacy Framework and the UK Extension, and its Data Processing Addendum additionally places transfers out of the EEA under the EU Standard Contractual Clauses, Module Two (controller to processor), which is the correct module for our relationship, since we are the controller and they process on our instruction. Those clauses are governed by Irish law with disputes before the Irish courts.

8. Deleting your data

The console gives you two controls with different scopes.

Clear all, in the Messages pane, deletes your observation records and nothing else. Your access token and your saved scenario selection survive.

ERASE EVERYTHING is the full one. It permanently deletes your observation records, your saved scenario and your MCP access token, terminates your live sessions, and signs you out. All three deletions are real deletions, not flags, and they run in a single transaction. It cannot be undone.

Because we hold no separate account record, those rows are everything of yours we have. There is no further account-deletion step to perform.

One thing the button cannot do. It does not revoke this application's access to your Google or GitHub account. That permission lives with them, and you have to remove it in your Google or GitHub account settings.

One limit on "permanently". Deletion removes the rows from the live database immediately and irreversibly. It cannot reach the daily volume snapshot described in §6, which is retained for five days in the same Amsterdam region before it ages out. So a record you delete today is gone from the service at once, and gone from our infrastructure entirely within five days. Snapshots exist for disaster recovery, are not queryable as a database, and are not consulted to answer anything.

Neither control removes the unattributed records described at the end of §4.3. Those carry no account, so there is nothing to match them to you. The seven-day rule clears them.

You can also email privacy@getcakewalk.io and ask us to delete your data.

9. Google user data

We use Google Sign-In only to identify you and create your account. We request the userinfo.email scope and nothing else.

Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not transfer Google user data to third parties except as described in §7, do not use it for advertising, and do not allow humans to read it except where necessary for security, to comply with law, or with your agreement.

10. Your rights

Under the GDPR you have the right to:

· access the personal data we hold about you, and receive a copy

· rectify data that is inaccurate or incomplete

· erase your data, and §8 gives you a self-service route

· restrict processing in certain circumstances

· data portability, meaning you receive your data in a structured, commonly used, machine-readable format

· object to processing based on our legitimate interests, on grounds relating to your particular situation

To exercise any of these, email privacy@getcakewalk.io. We will respond within one month.

If you think we are processing your data unlawfully, you can complain to a supervisory authority. Ours is the Berliner Beauftragte für Datenschutz und Informationsfreiheit, Alt-Moabit 59-61, 10555 Berlin. You may also complain to the authority where you live or work.

11. Security

The Test Kitchen runs on infrastructure kept deliberately separate from the Cakewalk platform. The platform's SOC 2 and ISO 27001 scope does not cover it, and nothing in this notice should be read as implying otherwise.

What we can state:

· Connections to the service are served over HTTPS, enforced at our hosting provider's edge. The application additionally sends a Strict-Transport-Security header with a one-year max-age, so a browser that has visited once will refuse plain HTTP afterwards.

· The application and its database communicate over our hosting provider's private network, and the database is not exposed to the public internet.

· Your access token is not stored in plain text. It is held as a hash for lookup plus an encrypted copy so the console can show it to you again, which means it is recoverable by design rather than one-way.

· Requests to the MCP endpoint are rate limited, as are console actions.

Encryption at rest. Your records are stored on our hosting provider's managed database and volumes, and are protected by whatever encryption that platform applies by default. We do not add an application-level encryption layer on top of it, and this notice does not claim we do.

12. Who at Cakewalk can see your traffic

· There is one internal operational view available to Cakewalk staff. It shows account counts and observation counts with email addresses masked to their domain, and it does not expose the content of any record. Access requires a Cakewalk staff account.

· Staff with direct database access can technically read stored records, as at any provider.

We do not keep a record of which staff member opened this view.

13. Children

The Test Kitchen is a developer tool and is not directed at children. We do not knowingly collect data from anyone under 16.

14. Changes to this notice

We may update this notice. The current version is always at https://www.cakewalk.security/mcp-test-kitchen/legal/privacy, with the date at the top. If we make a significant change we will say so on the landing page.

15. Contact

privacy@getcakewalk.io

Cakewalk Technology GmbH, Hardenbergstraße 32, 10623 Berlin, Germany