The /access page is the live, single-screen view of who can do
what inside your Kommit-governed AI surface. Every user, every
agent, every connected system — listed against the actions they're
authorised to take, with the policy that grants the authorisation
visible inline.
Why this exists
Most companies running AI agents in production end up with access sprawl in less than a year:
- —Agents accumulate tool permissions ad-hoc, granted by whoever was on call when the agent needed access.
- —Production credentials sit in three places: the secret manager,
the agent's environment, and someone's
~/.zshrc. - —Off-boarding misses the agents an employee built / configured / granted access to.
The /access matrix is one screen that makes all of this
auditable in 30 seconds.
Anatomy of the matrix
Rows: every principal (user, agent, system service). Columns: every action class (read, write, approve, configure) on every governed system. Cells: the policy that grants or denies the action, with a click-through to the policy itself.
Cells render in three states:
- —Green — authorised, with at least one policy granting it.
- —Yellow — conditionally authorised (requires approval per the active policy).
- —Red — explicitly denied or not granted by any policy.
Filtering at the top lets you narrow by principal type, system, or action class. The default view groups by principal so you can scan one user / agent at a time.
How a cell changes
The matrix is read-only. You don't grant access by clicking a cell — you author or edit a policy in the Policy library (see [#policy-library]) that grants the access, and the matrix reflects the new policy on save.
This is intentional. The matrix is a view on the underlying policies; if the view were directly editable, you'd lose the policy-as-source-of-truth contract, which is what makes the audit trail defensible.
Common setups
| Setup | When |
|---|---|
| One agent, one tool | Start with a single policy granting the agent the tool, with require_approval for any irreversible action (writes, deletes). |
| Multiple agents, shared tools | Group agents by role; write per-role policies. Avoid per-agent policies — they don't scale. |
| Production vs. staging | One policy bundle per environment, with staging permissive and production requiring approval for every tool above read-only. |
| Off-boarding | A single policy that removes all of an off-boarded user's grants in one edit. The audit-log row for that policy edit is your off-boarding receipt. |
Verifying the matrix matches reality
The matrix shows the intended access. The reality is whatever the downstream systems actually accept. To verify alignment we recommend:
- —Run the
kommit access verifyCLI command on a schedule (it tests each green cell by attempting the action with a dry-run flag the agent supports, where the tool offers one). - —Alert on any green cell where the downstream system rejects the action — that's drift between Kommit's view and the ground truth, and it's the kind of thing auditors find.
Limitations today
- —The matrix is per-tenant. Cross-tenant or cross-org views are not in the product today.
- —The matrix doesn't show historical grants — for that, query the audit log directly. See [#exporting-audit-logs].