Privacy Policy — Probe MCP Addendum
Summary: Probe MCP runs software inside your network and reaches your devices directly. That makes it different from our other MCP servers, and it is why it has its own addendum rather than being covered by the MCP Products Addendum. It collects network telemetry, a device inventory including MAC addresses, and — when you ask for them — packet captures and recorded SSH sessions.
Contents
What Probe MCP is
Probe MCP has three parts:
- The probe — a container you run on a host inside your own network. It observes the local network over syslog, SNMP, sFlow, packet capture and SSH, and connects outbound to our cloud engine through an encrypted tunnel. These protocols do not leave your local network; the probe is what reaches them.
- The cloud engine — a Cloudflare Worker that receives what the probe sends, stores part of it, and answers queries.
- The dashboard and MCP server at probe-mcp.lanpulse.com — where you create an account, enrol probes, and connect an AI agent (such as Claude) that can query your network through the Model Context Protocol.
Why this addendum exists separately
Our MCP Products Addendum covers MCP servers that relay an agent's requests to a third-party platform you already have an account on, through that platform's own API, keeping no copy of what comes back. Probe MCP meets neither of the two conditions that matter most there: it runs inside your network and reaches your devices directly, and it retains a substantial part of what it observes. It therefore handles a different and heavier category of data, and this addendum — not that one — describes it.
How access is granted
Probe MCP has two different access relationships, and they are granted separately.
The dashboard is reached by signing in with Google, as described below. This is where you enrol probes and manage sites, credentials and connections.
An AI agent reaches your network through the MCP server, and only after you approve it on an explicit grant screen that names the client asking and the account you are signed in as. You can approve or deny, and you can revoke the resulting access later.
Read that screen carefully, because the approval is a single permission covering the whole tool surface rather than one permission per capability. Approving a client grants it everything the MCP server can do for your account — listing probes and devices, reading collected telemetry, running live queries, requesting packet captures, and opening command-line sessions to your devices. There is no way to grant a client the read-only part alone. Approve only clients you intend to give all of it.
Linking one of our other MCP servers to your Probe MCP account is granted on its own consent page, which names both accounts before you confirm. Because a link decides which account owns what, we keep an append-only record of every link, move and revocation, as described under Data collected.
Data collected
1. Account and identity data
You sign in to the dashboard with Google. We request the openid, email and profile scopes and store:
- Your email address (which must be verified by Google) and your name, if Google supplies one
- Your Google account identifier, so we can recognise you on your next sign-in
- Your organisation and role — a new Google identity creates its own organisation, and organisations are isolated from one another
- Session and API tokens, stored only as irreversible hashes, never as the token itself
We do not receive your Google password, and we do not ask Google for access to any other Google service.
2. Network telemetry from your probe
The probe sends the cloud engine:
- A device inventory for each site — MAC address, IP address, hostname, vendor, firmware, device type and role, and when each device was first and last seen. MAC addresses can identify a particular piece of equipment, and in the case of phones and laptops, a particular person's device.
- Device classification signals — mDNS service types, SSDP headers and LLDP descriptions the probe observes, and the device class it infers from them.
- Interface, radio and system counters collected over SNMP, and traffic-flow aggregates — top talkers, conversations and applications by volume. These are stored as metrics and summaries.
- Probe health — version, operating system, architecture, LAN address and heartbeat times.
Two categories deliberately stay on your probe and are not stored in our cloud:
- Syslog messages remain in the probe's local database and are queried on demand when you or your agent ask for them.
- Positional observations (wireless client presence readings) are held on the probe for about five minutes and are not persisted by the cloud engine at all.
3. Packet captures
When you or your agent request a capture, the probe slices its ring buffer and uploads a .pcap file to our storage. We keep the file, plus a record of the filter you asked for, the time window, and the packet and byte counts.
A packet capture can contain anything crossing the segment at that moment — including traffic belonging to people other than you, and including the contents of unencrypted communications. Request captures only when you are authorised to, and narrow the filter to what you actually need. Each capture is reachable through an unguessable download link that expires.
4. Device credentials and SSH sessions
If you use Probe MCP to reach a device's command line:
- Device credentials (a username with a password or private key, and the host and port they belong to) are encrypted before storage with AES-256-GCM using a key derived per organisation. Only the ciphertext is stored; we never store the plaintext secret and never return it after you save it.
- Each SSH session is recorded. We store an index row — which device, which user, when it started and ended — and the session recording itself, which captures the commands sent and the output returned. Treat anything typed or displayed in such a session as recorded.
5. Controller connections
You can connect Probe MCP to a network controller. You choose where that controller's credential lives:
- On the probe only — the secret stays inside your network and our cloud never holds a copy.
- In the cloud, encrypted at rest as described above.
- On the probe, with a temporary cloud copy — a "break-glass" copy you push deliberately, with an expiry you set, so that queries survive a probe outage. An expired copy is refused at use and deleted by a job that runs every five minutes.
6. Assessment reports
If you generate a network assessment report, we store the report, and — where you supply them — the requesting email address and company name associated with it. Reports are reachable through an unguessable link that expires.
7. Usage and audit data
- MCP call records — which tool was called, when, whether it succeeded, and how long it took
- An audit log of significant account actions
- An append-only record of account links to our other MCP servers, described below, which outlives the link itself because a moved link is a change of tenancy
Sharing
- Google — used to sign you in. Google's privacy policy governs that step.
- Anthropic — when you connect Claude, your instructions and the data returned by your queries flow through Claude. Anthropic's data-use terms govern that. If you connect a different agent, that provider's terms govern instead.
- Cloudflare — our hosting, database, storage and tunnel provider, as described in the Master Privacy Policy.
- Our other MCP servers — you may link your Probe MCP account to a NeuralConfig sibling server (
r1-mcp,sz-mcporcp-mcp). If you do, we store the identity that server knows you by and the verified email attached to it. You may also configure Probe MCP to forward telemetry to one of those servers. Both are off by default and both are your choice.
We do not sell your data, and we do not share it with anyone else except as the Master Privacy Policy describes for infrastructure providers and legal process.
Retention
- Packet captures and assessment reports carry an expiry set when they are created, after which the download link no longer works.
- Temporary break-glass credential copies are refused once expired and removed by a sweep that runs every five minutes.
- Device inventory, telemetry summaries, usage records and audit entries are retained while your account is active.
- Syslog and positional data are governed by your probe, not by us — stopping or removing the probe ends their collection immediately.
- Anything else, including credentials, session recordings and stored captures, is retained while your account is active and deleted on request as described below.
Your choices and rights
- The probe is yours. Stopping or removing the container ends all collection from that network at once.
- Configure what it watches. What the probe collects depends on the collectors you enable and the devices you point it at.
- Delete a controller connection from the dashboard. Where the secret lives on your probe, deletion removes it from the probe's vault too.
- Revoke a link to one of our other MCP servers at any time.
- Request deletion of your account and its data by writing to [email protected]. We will confirm the scope with you before acting, because deleting an organisation removes the device inventory, captures, recordings and credentials belonging to every user in it.
- Standard rights from the Master Privacy Policy — access, correction, and the rest — apply.
Other people's data on your network
Probe MCP observes a network that other people use. Device inventories, traffic aggregates and packet captures can describe their devices and their communications, not only yours.
You are responsible for having the authority to monitor the network you point a probe at, and for meeting any notice or consent obligation you owe the people using it. Where we process that data, we do so on your instructions and on your behalf. If you need a data-processing agreement to cover it, write to [email protected].
Contact
For Probe MCP privacy questions: [email protected]. For product support: [email protected].
← Back to the Master Privacy Policy