The Anonymiser: confidentiality guardrails for agents

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

Agentic automation changes how professional software interacts with client data. A traditional application opens, processes, and closes. An agent does something more consequential: it plans, calls tools, reads results, forms new intentions, and calls more tools. Each one of those tool calls is a data movement event. Each one carries a question that 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 architectural concern. Professional secrecy attaches to each of those movements. The obligation does not pause because an agent is doing the work rather than a human. If anything, it sharpens. The volume and velocity of agentic tool calls make the confidentiality architecture more important, not less.

The problem with a single anonymisation policy

Most privacy-aware AI systems operate with a binary model: either data is anonymised before it leaves a defined perimeter, or it is not. That binary made sense when AI interactions were simple. It does not hold up in an agentic context, where a single workflow may need to write a record back to a portfolio management system, retrieve a commentary article from a legal database, generate a chart from aggregated numbers, and search public company data via an external API.

These four actions have fundamentally different confidentiality requirements. Applying the same anonymisation rule to all of them is either too restrictive (preventing a portfolio system from receiving the client identifier it needs to match the correct record) or too permissive (sending a real client name to an external search provider that has no legitimate reason to hold it).

The Unplex Anonymiser resolves this by classifying every tool call into one of three trust levels before any data moves.

Three levels. One clear principle.

The classification 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 via SharePoint holds the actual engagement letter. Sending anonymised tokens to these systems would break the connection: the system cannot match a placeholder to a real record. For trusted tools, the anonymiser deanonymises on the way in, restoring the real identifier so the tool can execute correctly. On the way out, it re-anonymises the response, applying the known mapping and scanning for any fresh personal data the system may have included in its reply. The real identifier never enters the broader agent context beyond this specific exchange.

Shielded tools are third-party services that perform a function but have no legitimate need to see client identities. A legal research database such as OnlineKommentar processes a query about a statutory provision. An external web fetch tool retrieves a public document. A case law service returns BGer decisions. None of these services need to know which client the research is for. For shielded tools, tokens stay as tokens. The anonymised placeholder passes through unchanged. On the way out, the response is scanned and any incidental personal data is scrubbed before it re-enters the agent context.

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

The table above shows the full classification with representative connectors at each level.

Why the distinction between in and out matters

The two-directional logic, what happens on the way in versus what happens on the way out, is worth pausing on. It reflects a specific threat model.

The inbound direction addresses the risk of sending PII to a system that should not receive it. For shielded tools, the anonymiser ensures that the query dispatched contains no real identifiers. The external service receives a structurally valid request with placeholders in place of names.

The outbound direction addresses a different risk: contamination of the agent context. A trusted tool may respond with a record that contains personal data beyond what was requested. A shielded tool may return a document that incidentally contains a name. If this data enters the agent's working context unprocessed, it can propagate into subsequent tool calls, into generated documents, into logs. The outbound re-anonymisation step prevents this. Every response is treated as potentially containing fresh PII, and it is scrubbed before the agent continues.

Together, these two directions contain the data within its appropriate scope. Trusted data stays in the trusted channel. Shielded requests stay anonymous. Neutral operations do not introduce personal data into flows that do not need it.

The anonymiser as a governance instrument

Professional secrecy is sometimes framed as a constraint on what technology can do. The Unplex Anonymiser inverts that framing. It is not a brake on agentic automation. It is what makes agentic automation deployable in regulated professions in the first place.

A wealth manager using the Agents product to prepare a client meeting brief pulls from Assetmax (trusted), aggregates market data from Infront (trusted), enriches with a publicly available company overview (shielded), and generates a formatted document (neutral). The anonymiser applies a different rule to each step without requiring the user to configure anything. The classification is embedded in the tool definition itself, governed at the platform level, not left to individual discretion.

The same principle holds for a lawyer using the agent to research a contractual issue: the firm's document store (trusted), FedLex for statutory text (shielded), OnlineKommentar for commentary (shielded), a file operation to save the output (neutral). Each hop has the correct guardrail applied automatically.

This is what a confidentiality architecture for agentic automation actually looks like. Not a blanket policy. Not a contractual warranty. A systematic, tool-level classification that determines precisely what data moves, in what form, to what destination.

Contractual layers still apply. They are not sufficient on their own.

The Anonymiser operates at the technical layer. Data processing agreements with every subprocessor, Hilfspersonenverträge for Swiss professional secrecy obligations, and AVV per GDPR and nDSG operate at the contractual layer. Both are necessary. The order matters.

A contract defines obligations and creates remedies. It does not prevent a data movement from occurring. The Anonymiser prevents the movement itself by ensuring that certain categories of data never reach certain systems. The contractual layer then governs what happens if something goes wrong at the edges of that perimeter.

Professionals subject to secrecy obligations cannot rely on contracts alone. The obligation attaches to the professional, not the vendor. An architecture that contains the data technically, and backs it with contractual protections, meets the standard that regulated practice demands.

Judgment defines your firm. Automate the rest.

For technical documentation, compliance questionnaires, or a walkthrough of the Anonymiser in your specific workflow, visit unplex.ai/trust-center or contact your account team.‍