Trust pack for security reviews | kanman documentation

This page collects what a security, privacy or AI governance review of kanman usually asks, in one place. Each section links to the page with the details. If your review needs something that is not here, write to [email protected].

What kanman is, and what it is not

kanman is an AI teammate for engineering teams. It takes stories from your tracker, works on them in isolated runs, has every change checked by your CI and by an independent reviewer against the story’s acceptance criteria, and opens a pull or merge request for it. It talks with your team in the app, in Slack and in Microsoft Teams.

kanman can:

draft stories from requirements and ask questions when something is unclear;
change code in the repositories your team’s policy allows, on a branch of its own;
run your tests, open pull or merge requests and merge them when your CI and an independent review passed;
review changes and answer questions about your code and your work.

kanman cannot:

reach repositories, branches or paths your policy does not allow;
push to protected branches or merge past your code host’s own merge and approval rules;
spend beyond its team’s budget;
see the values of secrets in its logs or records;
train a model on your data: kanman does not train or host its own model.

kanman is not designed to evaluate people. Its reports describe how a team delivers, never how an individual performs.

How control is kept

How far kanman goes on its own is set by people and recorded in the audit log:

The policy decides which repositories and paths kanman may change and how much it may spend. See Policies.
Merging needs green CI and an approval by a reviewer that did not write the change, enforced outside the model. Your code host’s protected branches and approval rules apply on top, so a team that wants a person to approve every merge sets that on the code host. See Merging.
Questions go to people only for what kanman cannot find out itself: intent, choices and access. See Questions from kanman.

Data flows and regions

	kanman Cloud	Your own runners	Everything on your runners
App, board, decisions, audit log	EU (Stockholm, Sweden)	EU (Stockholm, Sweden)	EU (Stockholm, Sweden)
Repository checkout and the coding agent	A fresh machine per run in Frankfurt, Germany	Your network	Your network
Repository actions (push, pull requests, comments)	kanman, from the run’s machine	Your runner	Your runner
Model calls for kanman’s own steps	kanman’s cloud, to the route your team uses	kanman’s cloud, to the route your team uses	Your runner, with your model access
What comes back to kanman	Run records	Progress, diff summary, commit information, transcript	Status, summaries, file names and links; no transcript

Model calls go to the provider your team’s route names. With EU-only processing switched on, kanman uses EU routes only and refuses every other route before a request leaves. Every model call and every run records the region its model ran in.

Details: Hosting and data residency, Run everything on your runners, What model providers see.

Subprocessors

kanman uses a small number of subprocessors. The current list with company names, locations, purposes and safeguards is Annex 2 of the DPA (English, German).

Purpose	Region
Hosting of the app and your data (database, sign-in, file storage)	EU (Stockholm, Sweden)
Run machines in kanman Cloud (not used with your own runners)	Frankfurt, Germany
Content delivery, DDoS protection, DNS	USA, global network
Payments	Ireland
Model providers, only when you pay through kanman: Anthropic, OpenAI	Global processing, outside the EU guarantee; see EU-only processing

With your own key (Anthropic, OpenAI, Amazon Bedrock, Azure OpenAI, Google Vertex AI on your runners, or your company’s AI gateway), the provider works under your contract and is not kanman’s subprocessor. Slack and Microsoft Teams store the messages there under your company’s agreement with them. See DPA and subprocessors.

Logging and retention

Audit log. Every policy change, answer, stop and resume, and every action kanman takes on your behalf, is an append-only entry with who did it and when. Owners and admins export it as CSV or JSON. Retention is a workspace setting from 90 days to 5 years, 365 days by default. See Audit export format.
Run records. Each run keeps its stages, progress lines, cost, policy decisions, and the model and region it used.
Model call records. kanman records every model call it makes: which step called, the model, the region, token counts, duration and cost. It stores no prompts and no answers, only a fingerprint of the input.
One trace per run. Every run carries one trace id that joins kanman Cloud, the runner and the coding agent. Runners can send each run’s trace to your own OpenTelemetry collector; see See kanman in your own monitoring.
Model quality checks. Once a day kanman asks each model route it pays for a small fixed set of graded questions. When the answers get worse beyond the route’s usual range, kanman’s operators are alerted and kanman stops using that route for its own steps until it recovers. This uses kanman’s own accounts only, never yours.
Deletion. A deleted team or workspace is erased completely and automatically after 30 days. See Retention and deletion.

Human oversight

Control	What it does
Questions	kanman asks people for intent, choices and access it cannot find out itself, each question once, in one place. See Questions from kanman.
Boundaries	Allowed repositories, denied paths, change size limits. Enforced while the agent works and again on the final diff. See Sandbox and secrets.
Budgets	Limits per run, per day and per month. See Budgets and cost.
Team pause	Stops new runs for one team; running work finishes. See Pausing a team.
Stop all runs	Stops every run of the workspace within a minute, on kanman Cloud and on your runners, and nothing is pushed after it. See Stopping all runs.
Checks before merge	kanman merges a change only when your CI is green and a reviewer that did not write it approved that commit. See How kanman checks its work.

The security floor

These rules hold on every team and cannot be switched off:

Instructions are not controls. Every limit that matters (paths, branches, production, spend, network) is enforced outside the model: by kanman’s run machine, by your code host’s protected branches and by the merge rule (green CI and an independent review). A limit that exists only as an instruction to the model does not count as a limit.
Only people with access can command kanman. Text from people without write access to the repository or the team, for example comments on a public issue or messages in a shared channel, never becomes an instruction for kanman. At most it becomes a finding that a person looks at.
The agent proposes, kanman’s run machine writes. The coding agent never holds a code host token. Only kanman’s run machine pushes and opens the pull or merge request, after scanning the change for credentials.
Redaction before anything is stored. Text from runs, agents and models passes a redaction step before kanman stores it, and the exact secret values of a run are removed from everything the run reports.
Every run is isolated. A fresh machine per run, only allowed repositories, a token that works for one run only. See Sandbox and secrets.
Outside text is data. Issue text, review comments, CI logs and dependency documentation reach a model marked as data with their source, and kanman’s own steps that read them answer in checked fields only. See Text from outside your team.
Monitoring tools stay as approved. When a monitoring MCP server changes its tools after kanman first read from it, kanman stops using it until an owner or admin approves the new tools. See Monitoring tools stay as approved.

On top of these rules, the coding agent’s internet access is limited to what the work needs, unless a team opens it: the code host, the package registries, kanman, the model and the hosts the team lists. It is enforced on the network level of the run’s machine, also on self-hosted runners, where production networks stay unreachable from a run. See Internet access while the agent works.

Incident and vulnerability handling

Report. Send security issues to [email protected] with a description and steps to reproduce. Please do not publish them before they are fixed. Every report gets an answer.
Triage. kanman assesses each report or detected incident for severity and affected workspaces and starts containment first; Stop all runs and kanman’s own stops for a model route or a run machine version are the tools for that.
Notification. For an actively exploited vulnerability or a severe incident, kanman follows the EU reporting path of an early warning within 24 hours and a notification within 72 hours, and informs affected customers. Personal data breaches are reported to you as the controller without undue delay, as the DPA sets out.
Gradual updates of the run machines. A new version of kanman’s run machines first takes a quarter of the runs and is compared with the version before it on how those runs end. If it does worse, kanman goes back to the previous version automatically and the runs that were on the new version continue on the previous one. When you update a self-hosted runner, its first runs are compared with the version before in the same way, and kanman contacts you when the new version does worse.
Daily model quality checks. kanman checks the quality of the model providers it pays for itself every day with fixed tasks, separately from your runs, and its operators are alerted as soon as a provider’s answers got worse; they can stop using that provider for every team at once.
Software bill of materials. A bill of materials for the self-hosted runner image is available on request.

AI marking

Everything kanman writes into your repositories and tracker is marked as AI work: a trailer on every commit, a label and a disclosure line on every pull or merge request, and the same line on tracker comments. See How kanman marks its work.

Alignment with ISO/IEC 42001

kanman aligns its practices with ISO/IEC 42001 (AI management systems). kanman is not certified; certification is planned. The table maps the Annex A control areas to where kanman covers them.

Annex A area	Where kanman covers it
A.2 Policies related to AI	Team policies; the security floor that holds on every team
A.3 Internal organisation	Workspace roles: only owners and admins change model access, EU-only processing, policies and stops; every change in the audit log
A.4 Resources for AI systems	Documented model routes per team, run machines and runners, budgets per run, day and month
A.5 Assessing impacts of AI systems	Merges only after CI and an independent review, your code host’s approval rules on top, budgets per team; kanman does not evaluate people
A.6 AI system life cycle	Acceptance criteria before work starts, your CI and an independent review before every merge, the activity log with the reason for each step
A.7 Data for AI systems	Data flows per mode, EU-only processing, redaction before storage, no training on your data, retention and deletion
A.8 Information for interested parties	This trust pack, the AI marking on commits, pull requests and comments, the audit log export
A.9 Use of AI systems	Questions from kanman, team pause, stop all runs, and the boundaries your team chooses
A.10 Third-party and customer relationships	Subprocessor list with regions in the DPA, your own key under your own contract, advance notice of new subprocessors

Alignment with the NIST AI RMF

Function	kanman features
Govern	Team policies, workspace roles, the security floor, the audit log with export and retention
Map	Data flows per mode, model routes and regions per team, what each model provider sees, what kanman can and cannot do
Measure	Your CI and the independent review on every change, the weekly report with the team’s service targets, model call records with region and cost, one trace per run, daily model quality checks, gradual updates of the run machines compared on run outcomes
Manage	Questions from kanman, budgets, team pause, stop all runs, EU-only processing, incident and vulnerability handling