Rules for agent setups

Configure your own rules for AI agent setups. kanman checks each repository against them, holds its own work to the ones you enforce, and reports in plain words.

Your organisation decides how AI agents should be set up and used. kanman gives you a set of checks to express those decisions as configuration. You turn on the checks you want, set their parameters, and choose for each whether kanman only reports or also enforces it.

  • Report: kanman checks and tells you what it found. Nothing about how your team works changes.
  • Enforce: kanman also holds its own work to the check, at the point where it acts (its push, its network access, its merge). Work by people is only ever reported, never blocked.

Defaults

Out of the box, only the checks about kanman’s own safety are on, in report mode: no access to production systems from kanman’s agents, marking of kanman’s commits, quality gates left as they are, review in a separate session, no real personal data in test data, and masking before model calls. Every other check is available and off until you turn it on.

A team can make the workspace’s configuration stricter, never looser.

Configure it

Tell kanman in the chat what you want, in your own words, or share your organisation’s guidelines as text or as a screenshot. kanman proposes a configuration as one card, shows what would change, and a lead or admin applies it with one tap. You can undo it the same way.

A neutral example: “Block our production network 10.20.0.0/16 for all agents, enforce it. Add the trailer AI-Assisted: yes to kanman’s commits. Report repositories without a linter in CI.”

The checks

Check What kanman looks at When enforced
Production blocklist Hosts and networks you list. kanman’s agents cannot reach them, also when a host name resolves into a listed network. Optionally, repositories carry a hook that blocks the same targets on developer machines. Always blocked for kanman’s agents.
Commit marking Every commit kanman pushes carries its AI trailer. You can add your own trailer. Your trailer is added to every commit kanman pushes.
Quality gates kept CI config, test, lint and coverage settings you list must not be removed or weakened. kanman’s review also points it out in people’s merge requests. kanman does not push such a change and asks a person instead.
Separate review Coding and review run in separate sessions; kanman never merges on its author’s own review. Always true for kanman’s work.
No real data in tests Test data files you list are checked for what looks like real personal or customer data. kanman does not push such data.
Masking before model calls Credentials, personal and customer data are masked before every model call. See Masking. Always on.
Agent config in the repository The repository has a checked-in agent config at the paths you choose. kanman proposes a minimal one as a merge request your team decides on.
Decision records Decisions have a place (paths you choose). kanman’s review notes architecture changes without a record. kanman offers to draft the record.
Repository health A periodic look at each repository from code analysis, the dependency tracker and CI. kanman names the gaps and offers to close the ones it can.
Model fallback Which model providers are set up and whether a tested fallback exists. kanman warns about a single provider.
Responsible person Each change kanman merges names a person: the assignee, the plan approver or the requester, in the order you choose. A change without such a person is not merged.
Repository baseline A list you choose: a linter in CI, SBOM uploads to your dependency tracker, static analysis, dynamic security tests, an agent config. kanman proposes merge requests for gaps it can close.
Working hours People hear from kanman only in their working hours, apart from urgent safety matters. Reports teams without working hours.
Personal opt-out People can tell kanman which work they would rather do themselves; kanman keeps it away from them. Report only.
AI share in merge requests Merge requests kanman opens end with “AI-generated: N of M commits, ~X% of changed lines”. Added to kanman’s merge requests.
MCP allowlist The MCP servers and connections you allow. kanman checks repositories’ agent configs against the list. kanman reads only from servers on the list.

Where you see the results

  • In the chat: after kanman checks a repository, one line such as “billing meets the team’s AI rules”, with a quiet status dot. Open it for the details.
  • In the weekly recap: one sentence, only when something is open or a check held something back.
  • In the activity log: every check, every held-back push and the responsible person of each merge, with their reasons, ready for an audit export.

Last updated: January 1, 0001

Open kanman