Privacy rules and audit

Tickets, emails, chat messages, tracker comments and CI logs often carry more than the work needs: a caller’s name, a customer’s email address, a contract number. Before kanman stores any text from a connection or sends it to a model, it checks the text and replaces sensitive values with placeholders such as [CUSTOMER_1] or [EMAIL_2]. The same customer always gets the same placeholder, so kanman can still follow a ticket from start to finish. The real value comes back only when kanman writes to the system the text came from, for example in a reply to the ticket.

You decide what counts as sensitive. Owners and admins set the rules for the whole workspace, and can let a team or a single connection adjust them.

Where the checks run

• kanman Cloud: the checks run in kanman before anything is stored.
• Your runner: if your workspace or a connection is reached through your own runner, the checks run on the runner, inside your network. Real values never reach kanman, and your own term lists stay on the runner as well (see Term lists on your runner).

The top of Workspace settings > Privacy says which one applies to your workspace.

Set the workspace’s rules

Open Workspace settings > Security > Privacy (/<workspace>/settings/privacy).

What counts as sensitive lists the categories kanman checks: people’s names, customers, email addresses, phone numbers, passwords and keys, and under more categories bank accounts, card numbers, postal addresses, IP addresses, customer numbers and contract numbers. For each category choose what happens to a value:

Passwords and keys are always checked and never put back.

Your own terms and formats holds what only your company knows, and is the one place for it: kanman also masks these before every model call (see Masking before model calls). Customer names (one per line) are right there. Under Number formats and own categories you find the formats of your customer and contract numbers as regular expressions, and categories of your own, such as project code names or internal systems; the name becomes the placeholder, so Project gives [PROJECT_1].

How values are found sets the checks, in the order they run:

1. Fixed patterns: emails, phone numbers, IBANs, IP addresses, keys and your own formats.
2. Local recognition: finds names, companies and addresses in German and English text.
3. Model step: a model on an endpoint you choose marks what the other checks missed. It can be your own GPUs, rented GPUs or a dedicated EU provider; any OpenAI-compatible endpoint works. Set it under Model endpoint. If your runner calls the endpoint, you only enter the name of the runner’s environment variable that holds the key; the key never leaves your network.

Hold items when a check fails is on by default: if a check is unavailable, the item waits and the team is told, and the raw text is never passed on.

Every change saves as you make it, can be undone for a few seconds, and is recorded in the audit log.

Test your rules

The Try it card shows what kanman would store. Paste a ticket, an email or a log line, or select Use an example. While you type, you see the text with placeholders, how many values were replaced per category, and how each check did. The test uses the rules on the page as they are, saved or not, so you can try a change before you rely on it. Nothing you paste is stored. For a scope checked on your runner, the test runs on the runner, with its term lists.

Teams and connections

The workspace’s rules apply everywhere. Two places can add to them:

• A team: open the team, then Team > Connections > Privacy.
• A connection: open it from Workspace settings > Connections and unfold Rules for this connection under Privacy.

A team that follows the workspace’s rules says so in one line; Set rules for this team only opens the same cards as the workspace. A change there applies to that team or connection only; Use the workspace’s rules removes it again. Term lists of a team or connection add to the workspace’s: they can add protection, never take it away.

The lock next to each setting in the workspace’s rules decides whether teams and connections may change it. By default, Hold items when a check fails and Passwords and keys are locked. A locked setting shows Set by workspace on the team and the connection. The card Teams and connections at the end of the workspace’s page lists every team and connection, whether it has rules of its own, and where its checks run.

Term lists on your runner

When a scope is checked on your runner, its customer names, formats and own categories never reach kanman, so you don’t type them into the settings. Instead, the card Your own terms and formats shows:

• the environment variable KANMAN_PRIVACY_POLICY_FILE, which names the file on the runner;
• the file itself, with an example already in the right place for the team or connection you are looking at.

Copy both, put the file on the runner and replace the example entries with your own. The file has the same structure as the settings, with one part for the workspace, one per team and one per connection:

{
  "workspace": { "categories": { "customer": { "terms": ["Example Customer GmbH"] } } },
  "connections": {
    "<connection id>": { "categories": { "contract_id": { "patterns": ["\\bCT-[0-9]{6}\\b"] } } }
  }
}

The runner reads the file at the start of every check, so you don’t need to restart it.

Privacy audit

Workspace settings > Security > Privacy audit (/<workspace>/settings/privacy-audit) is for owners, admins and the people who review your data protection. It shows counts only, never values.

• Checked text: items checked, values replaced and items held over the last 7, 30 or 90 days, with a chart per day. Use the arrow keys on the chart to read each day.
• By category and connection: which kinds of values were replaced, and from which connection.
• Held items: items that waited instead of passing on unchecked, with the reason.
• Active policy per connection: the rules each connection’s text is checked with right now, where the checks run, and whether items are held on failure.
• Detection quality: recall (the share of sensitive values that were found) and precision (the share of findings that were right) per category. Select Run quality check to measure again, for the whole workspace or one connection. kanman uses its own synthetic samples plus yours.
• Your samples: upload labelled examples from your own tickets as a JSON file to measure quality on real text. They are stored encrypted and used for quality checks only. For a scope checked on your runner, the samples stay on the runner instead: name the file in KANMAN_PRIVACY_SAMPLES_FILE.
• CSV and JSON export the audit for the selected period, for your auditors.

Related pages

• Masking before model calls
• Hosting and data location
• Runner-only workspaces