Security

Kenaptic writes into your published pages. That is a responsibility, and it shapes the whole design.

Most tools that touch your content ask you to trust them. We would rather show you the mechanisms, because the safeguards below are structural — they are how the product works, not policies layered on afterwards.

A person approves every change

Nothing is published automatically unless you have deliberately asked for it. Every proposed cross-reference and every content fix enters a review queue where a member of your team approves, edits or rejects it. Kenaptic is the analyst that finds the opportunity; your team is the editor that decides.

Automatic publishing exists, per source, above a confidence threshold you set — switched off everywhere until an administrator turns it on, and carrying a plain warning when they do. We don't recommend it, and we say so on the switch. If you do use it, everything else on this page still holds: the links are marked, they're reversible, and turning the switch back off withdraws anything it approved that hasn't yet gone out.

Every change is marked, and reversible in one click

A link Kenaptic adds is wrapped in explicit markers, so you can always tell what it contributed from what was already there. Because the boundary is unambiguous, removal is exact: retracting a link restores the page to precisely its previous state. On git-backed content that means closing or reverting the pull request; on API-backed platforms it means removing the block we added and nothing else. You are never locked in, and there is never a mystery about where a link came from.

Personal data is removed before anything is stored

Your estate contains people. Forum threads carry members' names and handles, support pages quote customers' email addresses, posts carry bylines. We do not want any of it.

Every page Kenaptic reads is stripped of personal identifiers at the moment of ingestion, before storage — email addresses, phone numbers, handles, usernames, byline and profile patterns are removed from the title, body and description. Everything downstream is built from the cleaned text, so the working copy, the search index and every request sent to a language model are clean by construction rather than cleaned up afterwards.

Two consequences worth stating plainly. Nothing personal reaches a model — the removal happens before any text is sent anywhere, and the detection itself is pattern matching that runs on our own infrastructure, because sending your text to a model in order to find the personal data in it would defeat the purpose. And it applies to every source, including your own: your forum belongs to you, the posts in it belong to the people who wrote them, and both are treated the same way.

▌ This is data minimisation applied to everything. It is not a claim that pattern matching can catch every possible form of personal data in free prose. Where a page must be excluded entirely rather than minimised, exclude it from the crawl.

We respect the rules a site publishes

KenapticBot identifies itself honestly and honours robots.txt as a complete opt-out, along with Crawl-delay, machine-readable text-and-data-mining reservations and noai/notrain directives. It never crawls behind a login and never bypasses a technical access control. Full detail is on the crawler policy page.

Your content stays yours

Kenaptic reads your pages to understand how they relate. It does not republish them. Community and forum content in particular is author-owned: we link to it and never reproduce it. Nothing from your estate is used to train a model, and nothing is shared between customers — each workspace is isolated, with its own database.

Platform posture

▌ Preparing a security review or a vendor questionnaire? Write to us from the About page and we will work through it with you.