This page is for the people who have to sign it off. It is longer and more specific than the rest of the site. A security review runs on detail, and a vendor page that answers in adjectives wastes your afternoon.
Indexing an archive means deriving face embeddings and voiceprints from your media. That is biometric data, with the obligations that carries, and it is the reason Mokuji is self-hosted by design rather than as an enterprise upgrade.
Deployed entirely in your environment.
Not a tier we withhold. There is no managed service and no vendor tenancy, so there is no shared-responsibility diagram to argue about. The one optional exception, sending GPU work to a cloud provider you choose, is off unless you turn it on, and is described in full below.
Where it runs
- Model
- Entirely within your environment, on hardware you own or lease. Indexing needs GPUs and ships as a containerized service stack. There is no version of this that is one small binary, and saying otherwise would waste your time.
- Egress
- None required. Mokuji sends no telemetry and makes no license check-in. Bundled third-party components ship with their usage reporting switched off. We recommend blocking outbound traffic at your firewall as well.
- Air gap
- Designed to run with no internet connection once installed; models are staged locally. A formal offline acceptance test is not yet part of the release.
- Public surface
- A single entry point, reverse-proxied. The standard install publishes no internal service ports; the databases and internal services are reachable only inside the deployment. The optional add-ons for multiple nodes and GPU captioning publish further ports without authentication of their own, so they belong on a private network segment.
- Media delivery
- Signed URLs rather than open file paths. Each signature covers one file and expires, after six hours by default, configurable, and it is not the user's session token, so a link that escapes into a chat log is not a standing grant of access. A collection can also be shared by link: anyone holding the link sees it without signing in, a link shared for editing lets them rate and label its clips, and the link works until sharing is turned off.
- Multi-node
- Scales by sharding whole assets across GPU hosts on your own network. Control traffic between the main node and its workers is mutually authenticated and encrypted. Workers reached through a relay receive signed, encrypted tasks and have no access to the databases; workers on the older shared data plane need it on a private network segment. None of them needs to reach the internet.
- Cloud processing
- Optional and off by default. If an administrator turns it on for a catalog (the agreement is recorded with who and when), that catalog's GPU work goes, encrypted end to end, to a cloud GPU provider you choose. What is sent: frames, the clips' audio, short transcript passages, on-screen text, captions, the names and places already found, and search queries. What comes back: text, boxes, and face and voice embeddings. The relay that routes it cannot read it; you run it, or we host it for you as an added service under a processing agreement. The worker keeps it in memory, or sealed with a key that exists only in memory, and drops it when each job ends. Databases, identities and voiceprints never leave; matching people stays on your server.
Who can see what, enforced where it matters.
Authentication and authorization
- Authentication
- Signed bearer tokens carrying user and role, with a configurable lifetime defaulting to seven days. Passwords use a per-user salt and PBKDF2-HMAC-SHA256 at 200,000 rounds, compute-hard rather than memory-hard, which we would rather state than dress up. Failed logins against a non-existent user pay the same cost as a real one. Repeated failures are throttled per client address and per username; the throttle is held in memory on a single instance. Sign-in is enforced by default, and the services refuse to start enforcing it without their secrets set.
- Authorization
- Role-based permissions decide what each user can change, such as editing transcripts, managing identities or administering the system. Collections can be shared with a team or with named users. Today any signed-in user can search and view the whole library; restricting viewing per asset or per team is on the roadmap.
- Enforcement point
- Permissions are checked by the services rather than only hidden in the interface, and role changes take effect within a minute. Disabling or deleting an account, changing or resetting its password, or removing its administrator flag ends its existing sessions across every service within about thirty seconds.
- API scope
- User tokens carry the user's role. Integrations use service-account keys with roles of their own. One internal token, used only between Mokuji's own services, has full access; it lives in the deployment's environment file and should be rotated at handover.
- Directory integration
- Not built in today. Tell us what you run, whether LDAP, SAML or OIDC, and we will scope the work.
What is encrypted, and who holds the key.
In transit
TLS terminates at the entry point, on your load balancer or a reverse proxy in front of Mokuji, with your certificates. Control traffic between nodes is mutually authenticated and encrypted. The internal plane is not exposed outside the deployment.
At rest
On your disks, under your full-disk encryption. The system's own secrets live in its environment file on the host, so protect that file as you would any credential. Work sent to a relayed or cloud worker is encrypted end to end.
Derived data
Descriptions, transcripts, embeddings and face crops live beside the media they came from, inside your storage.
Backups
A built-in scheduler writes backups off the box, encrypted to your public key, with the private key kept off the box, and there is a written restore procedure. Storage, schedule and retention are yours. We neither take nor hold a copy of anything.
Faces and voices, handled on your terms.
This is the section that decides most enterprise reviews, so it is the one written most carefully.
Derived identity data
- What is derived
- Face embeddings, face crops and voiceprints, generated from media you already hold. No external enrichment, no third-party lookup, no reference database we supply.
- Estimated attributes
- For each detected face the system estimates apparent age and sex. The estimates are shown on groups of unnamed faces to help a reviewer work out who they are, and are not offered as a search filter. An enrolled person's profile can also carry a gender your team enters, so scene descriptions can use their name instead of “a man” or “a woman”.
- Where it lives
- Beside the media it came from, on your storage. It is not transmitted to us. Unless you turn on cloud processing for a catalog it never leaves your network; if you do, frames and audio go, encrypted, to the GPU provider you choose, and only face and voice embeddings come back to be matched on your server.
- Regulatory position
- Keeping it on-premises supports obligations under regimes such as GDPR, BIPA and CCPA, because consent, retention and deletion stay answerable by your own policy rather than by a processor agreement with us. In the standard install we never receive your data, so we are not a processor of it. If you turn on cloud processing, the GPU provider you choose processes that work for you and is your sub-processor, not ours.
- Enrollment
- A person is named because somebody in your organization enrolled them, not because a model recognized them from somewhere else. Once someone is enrolled, the system can add further voice samples to their profile as it finds them.
- Deletion
- Removing an asset deletes its face crops, face embeddings, transcripts, descriptions and index entries. Its voice data and proxies are not yet removed with it, and deleting a person keeps their reference faces and voice samples; both are being fixed. Copies in your backups, and sidecar files written beside your media, follow your own retention.
- Retention
- Defined by you. Nothing is kept for us. Your administrators get a search log of the queries people run, not who ran them, which rotates after 90 days by default.
- Training
- Your media is never used to train anything. It never reaches us, and work sent to a cloud worker is deleted when each job ends.
We cannot reach your deployment unless you let us.
No support tunnel, no VPN back to us, no phone-home channel, no credential we hold. A deployment that is never granted access is never reachable by us at all, and most never need to be.
You send logs
The admin screen builds a diagnostics bundle in one click, with secrets redacted. It includes recent logs and searches, which can contain names, so review it before sending. Sending it grants us nothing.
You grant access
Where diagnostics are not enough, you open access to the deployment across your own network, scoped, time-limited, under your controls, revoked when it is done.
We attend in person
Where the support tier provides for it, an engineer works on the system on your premises, in front of you. Nothing leaves the site.
You decide which
Each time. There is no standing arrangement to audit and nothing to remember to revoke afterward.
Your privacy team should record a granted session as a disclosure for its duration. The DPIA support pack says the same.
What is recorded, and how releases are checked.
Operational assurance
- Audit trail
- Every change made by a person or an integration key, including corrections to transcripts and speakers, is recorded with actor, route, target and time in your own database, as is every change refused for lack of permission and every failed sign-in. Views are not logged yet, so a per-asset access log is not there.
- Testing
- Automated tests cover the services and the web interface.
- Release pipeline
- A gated pipeline with static analysis, dependency vulnerability checks and published checksums is being built. Until it is in place, releases are built by our own team.
- Evidence pack
- Architecture and data-flow diagrams and a dependency inventory are in preparation. Send your questionnaire; we would rather answer it early.
What this does not do for you.
A security page that only lists strengths is a brochure. These will come up in any real assessment, so they are better read here than discovered there.
It is not consent
Self-hosting keeps biometric data in your control. It does not establish that you had the right to collect it, or that the people in the footage agreed to being indexed. That remains yours.
It is not a hardened host
A server nobody keeps patched is worse than a well-run cloud tenancy. Mokuji removes a category of risk; it does not run your infrastructure or replace your controls.
Recognition is not proof
Identification is a ranked hint with a match score attached. Anything with consequences attached needs a human confirming it, and the interface is built to make that easy rather than to hide it.
It will be wrong sometimes
Descriptions and attributions contain errors. Everything is editable and corrections stick, which matters more in practice than first-pass accuracy.
Admins can see a lot
An administrator of your deployment can reach the material and the derived data. The access model constrains users, not the people who run it; that boundary is yours to staff.
We are not a processor
In the standard install we never receive your data. That is the point, but it also means the data-protection obligations sit with you rather than being partly transferred. If you turn on cloud processing, the provider you choose is your sub-processor, and that agreement is yours to hold. It should be a deliberate trade.
Found something? Tell us.
Reporting
- Where
- security@neurotik.io, or the details at /.well-known/security.txt
- Response
- Acknowledged within two business days, and you are kept informed while it is fixed rather than thanked and forgotten
- Credit
- Given unless you would prefer we did not
- Safe harbor
- Good-faith research against your own deployment is welcome; we will not pursue anyone for it
Send us the questionnaire.
We would rather answer the hard questions now than have them surface three months into a procurement. We will walk your team through the architecture and the deployment specifics.