Experimental privacy filter¶
Version 1.1.0 adds an experimental privacy filter, disabled by default. It is not present in version 1.0.0 or the recorded Windows tutorial.
privacyMode defaults to off, including profiles saved by earlier versions
without that setting. Normal responses can therefore contain personal data and
detailed errors. Existing explicit settings are preserved. To try the filter,
set "privacyMode": "minimize" on a profile, enable it in add-manager, or set
CCO_MCP_PRIVACY_MODE=minimize for all active profiles. Restart the MCP connection
after changing the setting.
When enabled, revenue reports, receipt amounts, articles, prices and quick-selection reads and writes remain available. There is no minimum receipt count: a report with one receipt still returns its amounts. The filter preserves rows and does not recalculate financial values. Its experimental status means you must assess its output and limitations for your use; enabling it does not establish legal compliance.
What the filter removes¶
When enabled, the filter inspects nested objects and arrays before sending a tool result to the AI assistant. It removes fields based on their names and entity context.
| Data | Behavior with experimental minimize enabled |
|---|---|
| Revenue, quantities, tax, discounts, payment totals and currencies | Keep, including individual receipt amounts and zero or single-receipt periods |
| Articles, prices, POS and organization identifiers, quick-selection nodes | Keep business identifiers and labels so the assistant can read and update them |
| Customer, business-partner, employee, cashier and operator details | Remove personal containers, names, contact details and identifiers |
| Audit identities | Remove fields such as createdBy, modifiedBy and the person who accepted a closing deviation |
| User records and cashier/customer report rows | Remove generic identity fields such as id, uuid and name in that context; retain financial values and non-personal status fields |
| Card and account identifiers, authentication data | Remove identifiers, secrets and opaque payment details; keep payment amounts and counts |
| Notes, comments, remarks, additional fields and user-defined fields | Remove because they can contain arbitrary personal data |
| Manager discovery | Keep readable display name, stable profile key, edition and privacy/read-only status; omit connection URL and login identity |
| Errors and startup diagnostics | Omit upstream response bodies, submitted values, account emails and connection addresses |
For example, a receipt can reach the assistant as follows. The item, quantity and amount remain useful; its customer, cashier, audit identity and comment are removed.
{
"id": "RECEIPT-1042",
"currency": "EUR",
"paymentGrossAmount": 8.5,
"salesItems": [
{ "material": { "externalID": "COFFEE", "description": "Coffee" }, "quantity": 2 }
]
}
Article descriptions and quick-selection button text are business labels and remain visible. A personal name written into an article description, button label, POS name or an unrecognized field can therefore still reach the assistant. The filter does not analyze the meaning of every string.
Available operations¶
Typed tools remain available for reports, receipts, day-end closings, articles, prices, quick selections, organization nodes and user administration. Supported writes still require a writable profile and the Manager account's permissions. Privacy filtering does not replace read-only access.
Three tools are unavailable with minimize:
ccom_requestaccepts arbitrary API paths and has no known response context.deploy_actionuploads executable code to POS systems.start_jobcan execute exports or send data through another service.
Action and job metadata can still be read, but opaque execution results, job parameters and messages are removed. Quick-selection image uploads remain available; the response does not include image contents or local file paths.
If every active profile uses minimize, those three tools are omitted from the
tool list. Mixed connections advertise the full set and enforce the selected
profile's policy on each call. Future tools require an explicit filter review
before becoming available in this mode. Use the stable key from list_managers,
even when two profiles have the same display name.
On fp21-demo, show August revenue by POS, including gross, net, tax and receipt count.
Then rename the Coffee button in the MCP Tutorial Cafe quick selection to Cafe special.
Configuration and implementation¶
The local operator controls the setting. off is the default and returns
unfiltered results; minimize explicitly enables the experimental filter.
The wizard defaults to no for new profiles and preserves an existing explicit
choice. CCO_MCP_PRIVACY_MODE overrides all active profiles in either direction.
An agent cannot change the mode through a tool argument. See
Configuration for examples and precedence.
The recursive removal approach follows the Integration Server's denylist rules, including audit identities, customer data, card details and arbitrary additional fields. The MCP filter also accounts for personal identities exposed under generic field names in user records and reports. It removes them without creating stable hashes or replacement identifiers.
Filtering creates a new response object before JSON serialization or truncation. Malformed report rows and entity collections are withheld if they contain free text instead of the expected objects. Raw entities remain local for internal operations such as GET, merge and PUT. Updating an article or quick-selection node therefore does not erase fields that were hidden from the assistant. Invalid tool arguments return fixed errors without echoing their values. Direct entity identifiers cannot redirect typed tools to arbitrary API paths.
Tests cover personal fields in nested arrays, preserved amounts and business labels, writes that retain the Manager's original fields, both authentication flows, concurrent profiles and separate MCP server instances. See Configuration for precedence and readable profile labels.
Scope and limits¶
This is data minimization, not a guarantee of anonymity or GDPR compliance. Detailed receipt amounts, timestamps and business identifiers can still reveal information when combined with other knowledge. Cashier reports retain amounts per row even though the identities are removed. Rows are not anonymous merely because their names are absent. Repeated queries and filters can also reveal information by comparison; this mode does not prevent such inference.
The filter covers known fields. New fields, custom business labels and personal data encoded under unrelated keys need separate review. The MCP server still processes the original Manager response locally. Data typed into a chat, uploaded images or files, browser sessions, other MCP servers and information shared earlier are outside this filter. It also does not filter receipts that the Manager forwards independently to an integration service; configure that service's own privacy controls. Restarting the MCP server does not delete past conversations or the AI provider's stored data.
Provider agreements and legal assessment¶
Where the GDPR applies and your model provider processes personal data on your behalf, Article 28 requires a controller-processor agreement, commonly called a data processing agreement (DPA; Auftragsverarbeitungsvertrag or AVV in German). Check the provider's role and whether its DPA covers your chosen service and use. See the EDPB guidance on controllers, processors and their contract.
A DPA alone does not make a deployment compliant. You are responsible for assessing your own use under the laws currently applicable to your organization and processing, including any required provider agreements. Review the purpose, necessary data, provider terms and relevant transfer requirements. Obtain qualified legal advice where needed. This documentation provides technical information, not legal advice; the experimental filter does not replace that assessment.