Kommit's Policy library is a set of pre-built controls that governs what your AI agents are allowed to do, who has to approve what, and what gets logged. You enable the policies that match your scope; we ship a starter set and you author the rest.
What a policy is
A policy in Kommit is a typed, versioned document with:
- —Trigger — what event causes the policy to evaluate. Examples: an agent run starting, a tool call being attempted, a data export being requested.
- —Conditions — boolean checks over the event's context. Examples: the agent's role, the requested tool's risk tier, the data classification of the resource being touched.
- —Action — what to do when the conditions match. One of:
allow,require_approval,deny,log_only. - —Approver(s) — for
require_approval, who is allowed to approve. Roles, named users, or a Slack channel.
Policies are stored in Postgres, version-controlled inside Kommit, and every change to a policy generates an audit-log row.
What ships in the starter library
The library is partitioned by intent. The starter set we ship today:
| Category | Example policies |
|---|---|
| Data handling | "Block agent reads of customer PII unless the agent is tagged phi-cleared." "Require Compliance approval for any export above 10k rows." |
| Tool authorisation | "Production database write requires Engineering Manager approval." "Sending external email requires Marketing approval." |
| Change management | "Policy edits require a second Owner's approval before taking effect." "Agent config changes are read-only between Friday 17:00 and Monday 09:00." |
| Audit / evidence | "All agent runs above $5 compute cost are logged at notice severity." "Every require_approval decision retains the requester, approver, and reason for the audit trail." |
You enable a starter policy with one click. You can then fork it into a customer-specific version that uses your roles, your named approvers, and your domain-specific conditions.
What's not in the library
- —Prompt-level safety policies (jailbreak detection, prompt-injection scoring). These typically live in your LLM provider's settings or in a guardrail framework like Llama Guard. Kommit's policies sit above that layer, not in place of it.
- —Per-customer business rules. "Agents may only act on invoices marked Net-30 in NetSuite" is custom to your business. The Policy library gives you the primitives to author this, but doesn't ship it.
Approval workflow
When a policy resolves to require_approval, the requester
sees the approval request in the dashboard or via the
notifications integration. The approver gets a notification
with a deep link, and approves or denies with a written
reason. The approval, the reason, and the requester /
approver identities all land in the audit log.
Approvals time out after a window the policy specifies
(default 4 hours). On timeout the policy's fallback action
runs — usually deny for high-risk policies, allow with
elevated logging for lower-risk ones.
Versioning + change management
Every policy edit creates a new version. The change-management
policy (policy.edit.requires-approval) requires a second
Owner's approval before a new version goes live, which is the
recommended setting for any environment that's in a real audit
scope.
You can view the diff between any two versions of a policy from the dashboard. Reverting to an older version is a normal edit — it creates a new version with the older content, not a rewind.