The Anonymiser: confidentiality guardrails for agents

Last reviewed: October 2026.

Not all tools are equal. Confidentiality guardrails need to reflect that.

Agentic automation changes how professional software handles client data. A traditional application opens, processes and closes. An agent plans, calls tools, reads results, forms new intentions and calls more tools. Each tool call moves data. Each one raises a question most platforms do not answer explicitly: what happens to the client data that passes through?

For lawyers and wealth managers, this is not an abstract architecture question. Professional secrecy attaches to every one of those movements. The obligation does not pause because an agent does the work instead of a person. It sharpens. The volume and speed of agentic tool calls make the confidentiality architecture more important, not less.

The problem with a single anonymisation rule

Most privacy-aware AI systems work in binary: either data is anonymised before it leaves a defined perimeter, or it is not. That worked while AI interactions were simple. It does not hold in an agentic context, where one workflow may write a record back to a portfolio management system, retrieve a commentary from a legal database, build a chart from aggregated figures and search public company data through an external API.

These four actions have different confidentiality requirements. One rule for all of them is either too restrictive, because the portfolio system never receives the client identifier it needs to find the right record, or too permissive, because a real client name reaches an external search provider with no reason to hold it.

The Anonymiser resolves this by assigning every tool call to one of three trust levels before any data moves.

Three levels. One principle.

The principle is the same in every case: does this tool legitimately hold the real data, and if not, should it ever see it?

Trusted tools already hold the client's real data. A portfolio management system such as Assetmax contains the client record. A document store accessed through SharePoint holds the actual engagement letter. Sending placeholders to these systems would break the connection, because a placeholder matches no record. For trusted tools, the Anonymiser restores the real identifier on the way in so the tool can execute correctly. On the way out, it re-anonymises the response, applies the known mapping and scans for any new personal data in the reply. The real identifier never enters the wider agent context beyond that single exchange.

Shielded tools are third-party services that perform a function but have no legitimate need to see client identities. A legal database such as Onlinekommentar answers a query about a statutory provision. A web fetch retrieves a public document. A case law service returns Federal Supreme Court decisions. None of them needs to know which client the research is for. For shielded tools, placeholders stay placeholders on the way in. On the way out, the response is scanned and incidental personal data is removed before it re-enters the agent context.

Neutral tools handle no personal data at all. A calculator, a chart renderer, a file operation on a document ID, a planning step: none of them touches client identifiers. The Anonymiser takes no action in either direction.

In short: trusted tools see real identifiers only for the exchange that needs them, shielded tools only ever see placeholders, and neutral tools see no personal data.

Why the way in and the way out both matter

The two directions address two different risks.

The way in addresses the risk of sending personal data to a system that should not receive it. For shielded tools, the Anonymiser makes sure the request contains no real identifiers. The external service receives a valid request with placeholders instead of names.

The way out addresses contamination of the agent context. A trusted tool may return more personal data than requested. A shielded tool may return a document that happens to contain a name. If that data enters the agent's working context unprocessed, it can spread into later tool calls, generated documents and logs. Re-anonymising every response prevents that. Each response is treated as potentially containing new personal data and cleaned before the agent continues.

Together, the two directions keep data within its proper scope. Trusted data stays in the trusted channel. Shielded requests stay anonymous. Neutral steps add no personal data to flows that do not need it.

A governance instrument, not a brake

Professional secrecy is often framed as a limit on what technology can do. The Anonymiser turns that around. It does not slow agentic automation down. It is what makes agentic automation usable in regulated professions in the first place.

A wealth manager preparing a client meeting brief reads from Assetmax (trusted), pulls market data from Infront (trusted), adds a public company overview (shielded) and generates a formatted document (neutral). The Anonymiser applies a different rule at each step without the user configuring anything. The classification sits in the tool definition and is governed at platform level, not left to individual discretion.

The same holds for a lawyer researching a contractual question: the firm's document store (trusted), Fedlex for the statutory text (shielded), Onlinekommentar for commentary (shielded) and a file operation to save the result (neutral). Each step gets the right guardrail automatically.

Contracts and certification still apply. Neither is enough alone.

The Anonymiser works at the technical layer. Data processing agreements with every sub-processor and auxiliary person agreements (Hilfspersonenverträge) for Swiss professional secrecy work at the contractual layer. Our checklist on professional secrecy and AI vendors covers that side in detail.

The organisational layer is certified. The information security management system behind the platform is certified to ISO/IEC 27001:2022 by SQS, the Swiss Association for Quality and Management Systems (reg. no. 48473, valid until December 2028).

A contract defines obligations and creates remedies. It does not stop a data movement. The Anonymiser stops the movement itself by making sure certain categories of data never reach certain systems. The obligation attaches to the professional, not the vendor. An architecture that contains data technically, backed by contracts and an audited management system, meets the standard regulated practice demands.

Judgment defines your firm. Automate the rest. Request a demo.

For technical documentation, compliance questionnaires or a walkthrough of the Anonymiser in your workflow, see our security page or contact your account team.