This week we explore a topic that touches every AI initiative in coworking and flex spaces: data privacy. In this new era of human-to-agent communication, it matters more than ever.

Operators are adopting AI tools at speed. Assistants that draft emails, agents that answer member questions, and agents that run the sales pipeline. Every one of them needs access to data to generate relevant outputs. And when we connect those agents to the systems through APIs, CLIs, MCPs and third-party integrations, we expose sensitive information to systems we don't fully control. Every AI agent that touches a database may be processing personal data.

That's why we think platforms need privacy built in by design. 

Privacy the operator does not have to configure, because the provider ships it as the default and sensitive data is never exposed in the first place.

Consider this example: a sales team asks an AI agent to pull recent leads who submitted a tour request form, qualify them, score them, and suggest personalised outreach.

The agent delivers valuable outputs. But to get there it may touch names, emails, phone numbers and other personal data. That's the core problem: we can't always control what data gets exposed to an LLM when agents interact with our systems.

But what if personal data were hidden by design?

Nexudus recently launched a feature that could set a new standard for AI-era data protection: PII Redaction. 

In the Nexudus developer tools, whenever a non-human actor accesses the data layer, PII is automatically redacted, on by default. As Adrian Palacios puts it: “automatic, code-enforced redaction of personal data whenever a non-human is on the other end of the line”.

For example, a team member asks Claude through any integration with Nexudus: "Show me the most relevant leads, high priority, registered in the last two hours." Here is what the LLM and the agent actually see:

The agent still does its job, without ever seeing the real personal information. Most workflows do not need it. Real names, emails, and phone numbers are not required to classify records, prioritise leads, or automate a process.

Move protection into the data layer and privacy becomes universal. Every assistant, automation, script and future tool inherits it automatically. No need to audit each new AI tool the team adopts.

Sensitive data is hidden by default. Privacy by design. 

Coworking is a trust business. Members trust operators with their data, and they expect it to stay inside the system they signed up for, not to end up fuelling someone's AI model.

Compliance keeps getting stricter. GDPR requires data minimisation. SOC 2 asks for defensible controls. Automated redaction, applied by default, is what stops personal data reaching the model in the first place.

In conventional systems, personal data is exposed by default and operators have to remember to hide it. In Nexudus, it is hidden by default.

Three examples show how the market is addressing this: Anthropic, one of the most relevant LLM providers; Nexudus; and Salesforce.

Anthropic recently launched Inference Hooks, a feature available in Claude Enterprise that lets the compliance team inspect and enforce policy on every prompt and tool call response before it reaches the model.

An employee runs a prompt, and the server returns a decision based on the organisation's policy. Claude enforces it in real time. See the image below.

What Anthropic built is a checkpoint that answers one question: should this content reach the model? It answers it for every Claude surface, from every source, before inference runs.

Security teams require every channel where employees can move sensitive data to pass through an inspection point they control. This is that point. It guarantees privacy, but only to the extent compliance has anticipated every scenario in advance.

When an organisation turns on inference hooks, every inference request routes through a signed WebSocket connection to a security server. Before the model starts generating, Claude sends the prompt and its surrounding context to the server, which returns a verdict: allow or deny. The same check runs on tool calls. When Claude calls a tool (MCP, skills, plugins), the response is inspected before it goes back to the model.

The verdict is binary. Inference Hooks do not rewrite and they do not redact. Content either reaches the LLM intact or does not reach it at all.

Here's how Nexudus is approaching data privacy.

The Nexudus CLI and MCP server replace personally identifiable information (PII) in every tool response with safe tokens before the response leaves the server. With redaction on, the AI provider only ever sees tokens like «PII:NAME:7f3a…», never the real names, emails, phones, or addresses of an operator's members.

When PII is redacted, sensitive fields are replaced with deterministic tokens:

Tokens are deterministic across calls within the session: the same member always maps to the same token, so the assistant can still answer questions like “How many bookings has this person made this month?” without ever seeing their name.

The checkbox shown in the image below is unchecked by default and redacts any member's personal data before it reaches the AI provider.

Leave the box unchecked when:

The assistant can still match the same person across calls, list members, count bookings, group by location, and run almost any reporting task on tokenised data.

More detail on how the CLI automatically redacts personally identifiable information.

And finally, how Salesforce is approaching this.

Before describing data masking, let's look at what the Einstein Trust Layer is: a collection of features, processes and policies designed to safeguard data privacy, enhance AI accuracy, and promote responsible use of AI across the Salesforce ecosystem.

To understand how it works, follow the data as it moves through the layer:

The Einstein Trust Layer identifies and masks sensitive data such as personally identifiable information (PII) in prompts before sending them to the LLM. It provides two types of masking:

1. Pattern-based masking uses advanced pattern matching and machine learning to detect sensitive data in prompts. Two examples:

2. Field-based masking uses metadata from Salesforce CRM fields to identify and mask sensitive data with placeholders. It builds on existing security controls like Platform Shield Encryption and Data Classification, which include compliance categories and sensitivity levels.

Once identified, the data is replaced with placeholder text so it is never exposed to external AI models, and the Trust Layer temporarily stores the relationship between each original entity and its placeholder. After the LLM returns a response, the layer demasks the data, so operators see the actual values in the response. See the image below.

The limitation is where it applies. Data masking for LLMs is disabled for agents. It remains available for embedded generative AI features (Einstein Service Replies, Einstein Work Summaries) and is configured in Einstein Trust Layer setup.

The three examples take different approaches to the same problem.

Anthropic's inference hooks act at the gate. The verdict is binary, allow or deny, which gives security teams a single control point they own across every Claude surface. The weakness: It limits the queries an employee can run rather than reshaping what the AI model sees.

Nexudus intervenes at the data layer. Personal data is replaced with tokens before the response leaves the server, so every assistant, script, and future integration inherits the protection without being audited individually. The weakness: the categories where redaction applies are predefined, though they cover the most common personally identifiable information. The list will keep expanding.

Salesforce and its Einstein Trust Layer mask sensitive fields on the way out and restore them on the way back, so the user still reads real values in the final response. The weakness: Data masking for LLMs is disabled for agents.

These are just three examples of how the market is addressing data privacy.

The coming years in coworking and flex space will be defined by how operators handle AI. There is no way back.

Operators who treat member data carelessly will erode the trust their members placed in them. Operators who build structural protections will become the obvious choice for serious companies, larger corporations, and regulated sectors.

Nexudus is building this privacy-first platform so operators do not have to figure it out alone.

That's it for today. See you in two weeks.