Data protection & security

Applies to Probe 0.364 and later.

What design information reaches a language model, where it is processed, whether anything is retained or used for training, and what a customer can do when design data may not leave their own environment. Written for an IT or security reviewer as well as for the engineer who will use the tool. Everything here describes the product as shipped today. Where a capability is a configuration choice rather than a fixed property, it says so.

1. The one fact that decides most of the rest

The only model inside Probe is a small local embedding model used for semantic search over datasheet text. It generates nothing and runs on the loopback interface.

The generative AI in the picture is the engineer's own assistant: Claude Code, GitHub Copilot, Cursor, or any other MCP-capable client, running on the engineer's machine under the customer's own account and agreement with that provider. The assistant asks Probe questions through MCP tools, reads the answers, and reasons over them. Probe is the assistant's tools; it is not the assistant.

This is why the same Probe server can be run with a cloud model, a cloud model inside the customer's own cloud tenancy, an enterprise-sanctioned assistant, or a fully local model, without any change to Probe. The LLM decision is the customer's, and it is made outside Probe.

2. What design information can reach the LLM

Because the assistant reads Probe through tool calls, whatever a tool returns becomes part of the assistant's conversation, and the conversation is sent to the assistant's model provider. Tool results can contain:

• Connectivity: net names, reference designators, pin numbers and pin functions, the components on a net, the nets on a component, power-rail topology and voltages.

• Parts: manufacturer part numbers, values, packages, catalog parametrics and lifecycle status.

• Review output: findings, the rule that fired, and the evidence cited for it, which is by design a readable excerpt of the connectivity, the BOM row or the datasheet passage that grounds the finding.

• Datasheet text: passages, tables and figures from datasheets the customer uploaded or Probe fetched.

• Images: rendered crops of schematic sheets and of copper, silkscreen and paste layers, returned as PNG when a question calls for looking at the drawing.

• Design intent: requirement and test text when Probe is federated with Trace.

Three properties matter for the risk assessment:

• It is a question-driven subset, not a bulk transfer. Nobody uploads the ODB++ archive, the Gerbers or the schematic PDF to a model provider. Probe returns what was asked for. Over a long review session, however, the accumulated results can describe a substantial part of the design, and a reviewer should assume that in the worst case the design's connectivity and BOM are reconstructible from the transcript.

• The conversation is re-sent on every turn. LLM APIs are stateless, so the assistant sends the conversation so far with each new request until it compacts it. Total volume transmitted is larger than the sum of the individual results.

• The assistant may also send things that never touched Probe. If an engineer asks their assistant to read a local BOM file or schematic PDF from their disk, the assistant reads that file into its own context first. That is the assistant's behaviour and the customer's file, and it belongs in an internal usage policy.

What does not reach the model through Probe: the raw uploaded archives, credentials, other users' identities beyond what the audit trail shows on request, and anything from boards the caller does not hold a role on where access enforcement is switched on (section 5).

3. Every outbound connection the Probe server can make

This is the complete list, taken from the code rather than from a description of intent. Each one is a configuration choice, and each is off by default or off when its setting is empty.

What is deliberately absent from the list:

• No telemetry. No usage reporting and no crash reporting to E-Sharp. Probe sends nothing to E-Sharp.

• No licence phone-home. Licensing is an offline, signed, node-locked file. No activation call, no heartbeat, no usage upload. The one licence artifact that travels to E-Sharp is the fingerprint, copied by hand and described below.

• No model-provider calls, as stated in section 1.

• No remote access for E-Sharp to a customer-hosted deployment. Support happens on the customer's terms, over whatever access they grant for the occasion.

On first start, a connected (non-air-gapped) install pulls Probe's container images from GitHub Container Registry and the embedding model from the Ollama registry. That is software coming in, not data going out, and the carry-in bundle (section 4) removes even that.

Acceptance check a customer can run: install the carry-in bundle on a host whose outbound firewall is closed. The install completes and every function except catalog lookup and datasheet fetch works.

The licence fingerprint

Deployments that run the licence authority activate and renew their licence with a fingerprint: a block of text the administrator copies from the server's licence page and sends to E-Sharp by email. E-Sharp answers with a signed licence file, which the administrator pastes back in. A standalone Probe-only install emits nothing at all.

• It is never sent by the software. A person copies it and sends it, at first activation and at each renewal.

• It is encrypted to E-Sharp with a random AES-256-GCM content key wrapped with RSA-OAEP-SHA256 to E-Sharp's public key. The private key is held offline.

• Its contents are enumerable: host identity (Docker engine id, one MAC address, an install id), node-lock observations, installed licence terms, licence history, daily usage counts per product, and pseudonymised per-identity activity (HMAC-SHA256 under a salt stored only in the customer's database, which E-Sharp cannot reverse).

The fingerprint does not contain any design data, board or project names, net names, part numbers, findings, datasheet content, real names, email addresses, error messages or log lines. The usage counts are the same figures the server shows the customer on its own usage page, so what is sent can be read before it is sent.

4. Deployment options

Probe is one product with one codebase. The options below differ only in who hosts it and what is configured. All of them give the customer the choice of LLM described in section 6.

4.1 On the customer's own premises (production, recommended for sensitive IP)

The Probe server runs on a host the customer owns, inside the customer's network. Two install paths exist:

• Docker Compose on Linux or Windows: API, MCP server, PostgreSQL with pgvector, Ollama and the optional Docling worker as containers. A carry-in bundle contains everything (images, embedding model, checksums, installer) for a host with no route to the internet.

• Windows-native install alongside Trace, with PostgreSQL, pgvector and Ollama installed natively and Probe run as scheduled tasks, for sites that do not run Docker on servers.

Design data lives in the customer's PostgreSQL database and the customer's file volumes. Encryption at rest, backups, retention and deletion are under the customer's control, on the customer's disks. E-Sharp holds nothing.

Reference deployment. A large multinational customer with a formal Infosec security-architecture review has taken the on-premises configuration through that review:

4.2 Hosted by E-Sharp for evaluation

For evaluations we host Probe on a server on E-Sharp's own premises in Sweden.

• Each evaluator connects through a personal WireGuard tunnel. The configuration is unique to the customer and routes only to the Probe server. The server has a private address and nothing is exposed to the public internet.

• One evaluation runs at a time. During the evaluation, only the evaluating customer and E-Sharp can reach the server.

• E-Sharp's demonstration boards are loaded. The customer may also upload its own designs.

• The customer's data is deleted from the server when the evaluation ends.

• No data-processing agreement is required. The evaluation terms apply and are accepted when the customer receives access to the evaluation server. See How your data is handled during an evaluation.

• The assistant-to-model connection still runs from the engineer's machine over their own internet connection, under their own account. It does not pass through E-Sharp.

• E-Sharp staff administering the server can, in principle, read its database. They do so only to run and support the evaluation.

4.3 What we do not offer

We do not run a multi-tenant Probe SaaS and have no plans to. The engineering record is either on the customer's host or, during an evaluation, on a dedicated E-Sharp server used by one customer at a time.

5. Security architecture of the server itself

• Authentication. Browser sign-in by OpenID Connect (authorization code with PKCE) against the customer's Okta or Microsoft Entra tenant. IDE assistants use a per-person key presented as a request header. A key carries no permissions of its own: it resolves to its owner's current roles on every call, so revoking a role takes effect on the next call. Keys expire after inactivity and are revocable immediately.

• Authorisation. Six roles: Viewer, Reviewer, Approver, LeadReviewer, Automation, Administrator. Every API route and every MCP tool declares the capability it requires; an undeclared route is refused. Enforcement can be introduced gradually: an Open state for a laptop, an air-gapped site or an evaluation server with no identity provider, a rollout state that records what enforcement would refuse, and an Enforcing state.

• Audit. Every write lands in an append-only audit trail with the actor, the entity and the change. Logs carry identifiers, tool names, payload sizes and elapsed time, never record payloads and never a credential.

• Transport. TLS terminated at a reverse proxy in front of Probe, with the customer's certificate. Service-to-service traffic stays on loopback.

• Vulnerability disclosure. security@esharp.se, with a published disclosure policy and safe-harbour statement, and reporting obligations under the EU Cyber Resilience Act where applicable.

6. LLM options and what each one means for the data

Probe places no restriction on the assistant. The choice below is the customer's, and it is where retention and training questions are actually decided.

A fully local model is a supported configuration and the only one where nothing leaves the building. The quality of an AI-driven design review, however, is bounded by the model's ability to plan and execute long chains of tool calls. We recommend evaluating a candidate local model against the demonstration boards before relying on it, and we will help with that.

Most assistants keep session transcripts on the engineer's machine (Claude Code does, in plaintext, for a configurable number of days). That is the likeliest place for design data to be over-retained, and it belongs in the customer's endpoint policy.

For exact retention figures and training commitments, the authoritative source is the customer's own agreement with the model provider and that provider's published trust documentation. We do not speak for them.

7. GDPR and data residency

Design data is not personal data. The GDPR questions are about the people using Probe, and they are small:

• Personal data Probe holds: for each signed-in user, the identity provider's subject identifier, display name and email address, for audit attribution and licence seat counting; the audit trail of that person's writes; and security events naming them. Nothing else.

• On-premises: the customer is the controller and the sole processor of its own deployment. E-Sharp processes nothing from it except the licence fingerprint described in section 3. No data-processing agreement is required for the product itself. A support engagement in which E-Sharp staff are given access is a separate, scoped arrangement.

• Evaluation on E-Sharp's server: the evaluation server runs without sign-in and holds no user accounts. Design data stays in Sweden and is deleted when the evaluation ends. The evaluation terms apply; no separate data-processing agreement is required. The model provider is a separate party under the customer's own contract; Probe is not in that chain.

• Residency of design data: on-premises, wherever the customer puts the host. Evaluation, Sweden. Model-side, per section 6.

8. How this answers the four questions we are usually asked

9. What we will provide on request

• The architecture and data-flow description above in the customer's own review template.

• The full MCP tool inventory with each tool's read/write classification and required capability.

• The security event schema, for SIEM onboarding.

• A carry-in bundle and the acceptance checks in section 3, for verification on the customer's own host.

• Help configuring assistant-side controls: retention settings, telemetry, transcript export and compliance logging for whichever assistant the customer chooses.

Contact: Daniel Rhodin, daniel@esharp.se · security@esharp.se