Packetman saysI'm Packetman. An agent that runs on every machine raises one question: what does it actually see, and where does the data go? Three answers. We never inspect content — TLS metadata only, no proxy. File reputation is hash-only — a 256-bit fingerprint leaves, never the binary. And your fleet's data is never merged with anyone else's. Below: the four-chip evidence cluster, where your data lives, and the binding policy.Three claims, each verifiable from how the product is built — not from what we say in copy. No content inspection. Hash-only file reputation. Customer-data isolation. Below that: how a "clean" verdict on a binary is reached, where your fleet’s observations physically live, and the in-product surfaces that let you see and change what we collect.
Companion to the Privacy Policy (binding), Terms of Service (binding), and the in-product privacy controls at every customer tenant.
Each of these is a hard line in the code, not a setting. The product cannot do these things on demand because the inspection paths don’t exist.
The agent observes connection metadata — source process, destination address, port, protocol, byte counts, timing, TLS handshake fields like SNI and ALPN. That’s it. There is no proxy, no man-in-the-middle, no certificate-substitution path, no decrypted-payload buffer anywhere in the agent or in the platform. TLS hides the prompts, the passwords, the documents, the videos — and we never try to break that.
The AI Governance dashboard is the cleanest worked example: we can tell you which AI vendors your fleet is talking to and how many bytes left for each, but the prompt itself is encrypted and we never see it. How that works →
When the agent observes a new executable, it computes a SHA-256 fingerprint and asks the reputation system whether the fingerprint is known. The binary itself never leaves your machine as part of normal operation. If the third-party services we query don’t recognize the hash, we mark the file unknown and surface it on your tenant’s Executables tab so an admin can decide what to do.
The opposite default — auto-uploading every unrecognized binary to a vendor cloud — is shipped by some EDR products. We think that’s the wrong choice for a tool that runs on every machine in your fleet. If an admin decides deep analysis is worth the privacy cost on a specific binary, they trigger that upload deliberately, on purpose, from their own desk. That’s a rule hard-coded into the product, not a configuration toggle.
Every flow record, host inventory, SBOM rollup, support conversation, and account row scoped to your tenant is your data. We process it only to provide the service to you. We do not pool customer data across tenants to train models, build aggregate “industry benchmarks,” or generate insights we sell back to anyone. The only data that crosses the tenant boundary is the global IP-reputation feed — which is a statement about an IP address, not about your fleet.
Tenant deletion is one click in the in-product privacy controls; it removes your tenant’s observations on the spot.
When we tell you a binary is “clean,” that verdict is the agreement of multiple independent sources — not one vendor’s opinion. The dashboard shows you exactly which sources said what, on every row, with click-through to the canonical record on each side.
Authenticode (Windows), codesign (macOS), or package signature (Linux). Asks: who claims to have made this, and is that signature cryptographically valid?
NIST’s National Software Reference Library. Asks: has a federal lab catalogued this exact hash as part of a known shipped software package?
MalwareBazaar (abuse.ch). Asks: have public researchers confirmed this exact hash as a malware sample?
VirusTotal’s 70+ commercial engines. Asks: what does the broad AV ecosystem think, aggregated across vendors?
Different questions, different evidence types. The cluster is the verdict — no single chip is decisive, and the dashboard never hides which chips agreed and which dissented. Deep dive on the four-chip cluster →
The same principle applies to IP reputation: a destination’s grade is the consensus of geo / rDNS, TLS certificate posture, infrastructure characteristics, public threat-intel feeds, and behavioral history — not one feed’s opinion. The investigation breakdown is visible on every destination drill-down.
The platform is built so the answer to “where do our network observations physically reside?” can be: where you say they reside.
The default tenant runs on DataStun’s cloud infrastructure. Region selection lands as we add regions. Tenant boundaries are enforced at the database row level today, with per-tenant DNS (*.tenant.datastun.com) and a path to per-tenant database isolation on paid tiers.
The reputation system is being split into multiple federated instances per region / customer. Tenants relocated to a region-local reputation instance phone home only to verify license; observations stay in-region. The federation model + relocation flow is documented in the architecture notes.
Custom-tier customers run the tenant platform and reputation system on their own infrastructure with the same code base. Observations never leave the customer environment except for the public IP-reputation pull (which is one-way, hash-style queries against the canonical reputation set).
For European-data-residency questions specifically: the data-sovereignty rollup on the Enterprise tier slices your fleet’s outbound bytes by destination country and tag (e.g. “non-EU destinations from EU-tagged agents”) so GDPR / Schrems II questions get answered with measurement rather than policy assumptions.
We don’t ask you to take any of this on faith. Every claim above is backed by a surface you can read, run, or change.
Per-data-class breakdown: every field captured by the agent, every retention window, every place it’s used. Ground truth for the Privacy Policy. Updated whenever we add or remove a collection path.
Read the data-collection page →Inside every customer tenant: see what’s collected for your tenant specifically, export a copy of your tenant’s data, and delete your tenant. No support ticket required.
Open privacy controls (tenant required) →The binding documents. Plain English where we can, formal where it matters. Every claim on this page is restated in operative form in the policy.
Privacy Policy → Terms of Service →DataStun is in pre-launch. The Privacy Policy and Terms of Service are binding on us as written today; both will be reviewed and tightened to operative legal language with counsel before commercial launch. We commit publicly to never collecting data we have not described in /data-collection. If anything on this page would prevent your organization from using the product as it exists today, please tell us before you sign up — that feedback shapes the policy.
Iris Locke
DataStun’s leadership voice
When a security reviewer asks what the agent sees, I don’t want to send them a promise — I want to send them the architecture. “No content inspection” isn’t a setting we leave on; the inspection path doesn’t exist in the code. Hashes leave, never your files. Your fleet’s data is never pooled with anyone else’s. That’s the kind of answer procurement signs off on without a three-week back-and-forth.
This page exists so a security or compliance reviewer at your organization can answer the “what does the agent see” question without reading the full Privacy Policy. The Privacy Policy is the next stop when that reviewer wants the operative language.