# AI employee approvals: open-source rules a reviewer can diff

> Security teams refuse AI employees when the only guardrail is a chat confirmation. Kortix is open source, and its approval rules are connector policy in a git repo you own: Allow, Ask or Block per tool, down to the arguments of the call.

URL: https://opensourceaiemployee.com/approval-first-ai-employee

## What an approval gate has to decide

A useful gate answers three questions about one call: which tool is being called, with which arguments, and who is allowed to say yes. Most products answer the first and stop. A tool-level switch cannot tell a read of one ticket from a read of the whole customer table. It cannot tell an email to a colleague from an email to a counterparty.

A refund makes the gap visible. The tool is the same every time. The amount, the customer and the order decide whether a person should look. A rule that matches only the tool name cannot express that, so the team ends up blocking refunds entirely or allowing all of them. Both outcomes lose the review.

Arguments carry the risk. A send action has a recipient and a body. A write action has a record ID and the fields it changes. If the rule cannot see those values, it is a warning label.

The approver is the third question, and the one teams answer last. Approving is an act inside the organization. What matters is who holds the permission, and whether a reviewer can read that without opening a vendor's console.

## Why human in the loop usually means a chat confirmation

The phrase covers two different things. One is a policy: a rule that holds a specific call until a named person approves it. The other is a dialog: the agent asks whether to continue, the message shows little about the call, and someone clicks yes to keep the work moving.

The dialog is easy to ship and easy to demo. It is also hard to audit. Nothing records what was approved in a form a reviewer can test, and nothing stops the same call from running tomorrow without a click. The gate lives in the conversation.

CellCog comes closest among the hosted products: its page says "Anything risky waits for your yes", and an approval card appears when the employee acts on your machine ([CellCog](https://cellcog.ai/ai-employees)). What counts as risky is decided in CellCog's console, so a reviewer reads a settings screen and takes the vendor's word that the setting applies to the call in front of them.

## What a reviewer can inspect when the rule is a file

A security review is a reading exercise. The reviewer wants to know what the employee may do, who changed that, and how to undo the change. A console gives a screenshot. A file gives a diff, a history and a revert.

Kortix keeps connector policy in the project repo, beside the agent's role file. A change to what the employee may do arrives as a commit, so the old rule and the new one sit on the same screen. The history says who changed it and when. A revert puts the old rule back without a support ticket.

Work follows the same path. Session work reaches `main` through a change request. Merge is default-deny for agents. The output and the rule that governed it get reviewed in the same habit.

The reviewer also asks where the work ran. One isolated sandbox per session. Each session has its own isolated machine and branch.

## Allow, Ask and Block, one call for each

The three actions only mean something with an example attached.

- Allow: read the support queue to sort today's tickets. The call runs and the agent keeps working.
- Ask: send a reply to a customer. The call holds, the card shows the action and the arguments it was given, and the agent resumes after a person approves.
- Block: delete a customer record. The call does not run, whatever the arguments say.

The assignment is a judgment about the call. A queue read with no filter touches everything, and the same read narrowed to `queue: billing` touches a working set. The labels help only when the rule can see the difference.

## The gates start off, so the first review is deliberate

Approval gates you set. Off until you set them. A new project therefore runs with no gate until someone writes a rule, and the honest reading is that the control exists because a person configured it.

Treat the policy as part of onboarding the role. Write the connector rules, review the diff, then let the employee take its first shift. The reviewer who signs off sees the rule before the work, which is the order a security team wants.

## The policy and the rule, as the repo states them

One file points at the role and names its reach; the README states the three actions and how an Ask behaves.

### kortix.yaml

`kortix.yaml`

```yaml
# kortix.yaml
agents:
  support-triage:
    file: agents/support-triage.md
    connectors: all
```

Source: https://github.com/kortix-ai/suna/blob/main/README.md

### The approval rule

`README.md`

```
Set each tool to Allow, Ask or Block, down to the arguments of each call.
An Ask holds the call until a person approves it, then the agent resumes.
Approval gates are off until you set them.
```

Source: https://github.com/kortix-ai/suna/blob/main/README.md

## What a security reviewer asks first

### Can an AI employee be trusted with production systems?

Only when the call itself is governed. Kortix applies connector policy to the action and its arguments, so a call marked Ask stops for a person before it runs.

### What is an approval-first AI employee?

One you run under an Ask-first policy. Any call you have marked Ask pauses until a person approves it, then the agent resumes from that point.

### Who approves an AI employee's actions?

Whoever your organization grants the approval permission to. The permission is set inside the project, and the connector policy that decides when to ask is a file a reviewer can read.

### Can I audit what an AI employee did?

Yes. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan.

## Set the gates before the first shift

Write the connector policy, read the diff, then start the session.

[Try Kortix](https://kortix.com) · [Read the docs](https://kortix.com/docs)

Self-host free · Any model provider, your own keys · Slack and Microsoft Teams are live