What model providers see

kanman does not train or host its own language model. The coding agent and the independent reviewer use models from established providers. This page explains which provider sees what, so you can assess it before you connect a repository.

Which provider is involved

The provider depends on the executor your team uses and on how you pay for compute.

The executor is chosen when you set up a team and can be changed in the team settings under Executor.

The reviewer deliberately uses a model from a different vendor than the executor, so that the work is checked by an independent second opinion. If your executor is Claude Code, the reviewer runs on an OpenAI model, and the other way round.

Intake (turning a requirement into stories) also uses a language model. It uses your own key when the team or the workspace has one, otherwise kanman’s model access.

Using your own key

A workspace has one provider key, which teams that are set to Use your own key share. Only workspace admins can add, test, replace or remove it.

1. Open Settings > AI providers (/<workspace>/settings/ai).
2. Click Add provider key.
3. Choose the Provider. Each provider is listed with the executor it works with: Anthropic and Amazon Bedrock for Claude Code, OpenAI and Azure OpenAI for Codex.
4. Fill in the fields for that provider (see the table below).
5. Click Test connection to check the key, then Save key.

After saving, the key shows its status (Working or Check failed), the model and when it was last checked. Use Test connection again at any time, Replace to enter a new key, or Remove key.

The key must fit the team’s executor: a team on Claude Code needs an Anthropic or Bedrock key, a team on Codex an OpenAI or Azure OpenAI key. kanman never falls back silently to its own model access. If the key is missing, removed or does not fit, the team’s runs stop with a clear message until you add a fitting key or switch the team to Pay through kanman.

Keys are stored encrypted and are only handed to the run’s sandbox as environment values. They never appear in logs, run records or the audit log.

What the coding agent sends

While it works, the coding agent sends its provider the context it needs for the task:

• the story: title, description, acceptance criteria, Demonstrate block and test plan,
• the policy summary for the run (denied paths, limits, budget),
• your team’s conventions and lessons that apply to the areas it works in,
• the files it reads from the repository, and the commands and outputs of its own tool calls (for example test output),
• the changes it writes.

It does not receive secret values (see Sandbox and secrets), other teams’ data, or other repositories.

What the reviewer sends

The reviewer receives the story, its acceptance criteria, the test plan and the diff of the change. It answers with a verdict per criterion, with file and line references.

What intake sends

When you submit a requirement in the app, in a chat with kanman or from a Slack thread, that text is sent to the model that drafts the stories, together with the team context needed to draft them.

What providers do with it

What a provider may do with the data is governed by that provider’s terms:

• Pay through kanman: kanman calls the provider under kanman’s business agreement. These agreements do not allow the provider to train models on your data. The providers kanman uses are listed as subprocessors in the DPA (see DPA and subprocessors).
• Your own key: calls run under your own contract with the provider. Your terms, your region choice and your data processing agreement apply. This is the usual choice for regulated teams.

Reducing what is sent

• Keep secrets out of stories and repositories, as you would for any developer.
• Use denied_paths to keep the agent away from areas it should not change, for example infrastructure or customer data fixtures.
• Use your own Azure OpenAI or Amazon Bedrock contract if model calls must stay in a specific region.
• Use a self-hosted runner if the checkout and the builds must stay in your network. Note that model calls still go to the provider you choose.

Related pages

• Plans and billing
• Hosting and data residency
• Budgets and cost
• Policy settings