MyPathKeeper MyPathKeeper

Findings leave the device. Content never does.

Media on a supervised device is examined on that device. What travels is a hash and a description — a filename, a path, a timestamp. The file itself is never copied, uploaded or stored by us.

Hashes and metadata only · Nothing uploaded · Findings are leads, not verdicts

Why we never take the file

A product that uploads and stores what it is looking for ends up holding the very material it exists to detect. We designed that possibility out rather than securing it.

🔐

Hashed where it sits

The agent reads a file, derives a cryptographic hash, and discards it. No copy is made — on our infrastructure or anywhere else.

📍

Left where it is

The agent reads a file and never moves, copies or alters it. A finding records the path and timestamps exactly as they were — better evidence than any copy a tool could make.

🧭

A lead, never a verdict

Holding no content means we cannot visually confirm anything, and we do not claim to. Findings are for someone with authority to act on.

📄

Gaps are reported

Files that could not be examined — cloud placeholders, permission-denied paths — are listed as unexamined rather than silently omitted.

What is built today

Working and verified against real devices and filesystems. Everything in this section exists now, on Android and Mac.

🖼️

Content-based media detection

Files are identified by what they contain, not their extension — including HEIC, the default iPhone camera format.

🎭

Disguised-file detection

An image renamed notes.txt is still identified as an image, and the mismatch is itself reported as a signal.

⚡

Incremental scanning

A full sweep once, then only what changed. A re-scan of 213,000 files completes in under ten seconds.

🔗

Known-material matching

The engine compares hashes against known-material lists and raises an alert on a match, retroactively re-checking earlier findings when a list is updated.

🧠

Classification on the device

Images are scored by a model that runs on the device itself — Android and Mac — so material that is on no list can still be referred. The pixels are never sent anywhere to be judged.

🎞️

Video, judged by persistence

A video is sampled across its whole length and flagged when explicit content is sustained over consecutive frames, not on a single worst frame.

📄

Document and filename signals

Document text and file names are checked against term lists the device only ever holds as hashes — including wording that raises a health & safety alert.

💽

Every drive the device can read

External drives, USB sticks, memory cards and network shares are scanned, and a drive is scanned within seconds of being attached. Backup volumes are skipped.

📍

A finding names the file

Each alert lists the files behind it with their full paths, why each was flagged, and its score — so a reviewer knows what to go and look at.

What is not built yet

Stated plainly, because a forensic tool that overstates itself is worse than no tool. If you need any of the following today, we are not yet the answer.

🚧

Known-material lists

Not in place. The matching engine works; access to the registries that supply the lists is being applied for. Until that is granted the product cannot detect known material.

🚧

A classifier you can rank by

Limited. One general model is shipped. Its score is a trigger to refer a file to a person, not a ranking: it is wrong in both directions, it does not estimate anyone's age, and it does not establish that anything is illegal. A second model is planned.

🚧

Windows and Linux

Not proven. The Windows and Linux agents build and share the scanner, but have not been run end to end on those systems.

🚧

iPhone and iPad files

Not possible. Apple gives no app access to another app's files, so an iPhone cannot be scanned. That is a platform limit, not a roadmap item.

🚧

Live detection on the node

In development. Detection in the traffic path during an active event, rather than on a scan interval.

🚧

Standalone media scanner

In development. A separate product for examining backups and stored filesystems outside a supervised device.

Where this fits

All of it is consented monitoring on a device the customer owns or is legally authorised to supervise. It is not covert, and it is not for monitoring another adult without their knowledge.

  • Court-ordered supervision — media analysis alongside the DNS record of where a device went, on the same reporting timeline.
  • Treatment programmes — where a condition of the programme covers device content as well as browsing.
  • Organisations — company-owned equipment, under a policy the device holder has been told about.

Tell us what you need to examine

Forensic engagements are scoped individually. Tell us the setting, the authority you operate under, and what you need to demonstrate — we will tell you honestly whether what exists today covers it.

MyPathKeeper is intended for lawful, consented monitoring — for example a parent protecting a minor, an organisation monitoring devices it owns, or another person you are legally authorized to supervise. It is not for covert surveillance of another adult.