What an agent control plane is, and where open source keeps the rule

An agent control plane is the layer that decides what a fleet of agents may do, and keeps the record of what it did. The term covers two different arrangements: one is a console above your agents, which IBM defines as "the system that deploys, operates, monitors and governs AI agents across an organization," a central point where policy is set and requests are routed. Microsoft sells Agent 365 to the same buyer, as "a control plane for IT and security leaders to manage AI agents" inside the admin tools a company already runs. The other keeps the rule in a file beside the agent, and Kortix is open source, so anyone can read the code that enforces it.

In that second arrangement the rules sit beside the agents, in files a team reviews before anything runs. Both can tell you that an agent acted and that policy allowed it. The question worth asking is narrower. When a reviewer asks why the rule said yes in March, which arrangement answers that without taking anyone's word for it.

The four jobs every control plane claims

Strip the vendor language and four jobs remain, whatever shape the product takes. Inventory finds the agents, including the ones a team deployed without telling anyone. Policy decides which tools, which data and which actions each agent may reach, and applies that decision at the moment of a call. Approvals hold a risky action until a person decides. The audit record writes down who did what, when, how they signed in, and whether it was allowed.

The vendors that sell this work do it for real. Astrix built its Agent Control Plane to discover agents a security team never deployed, including third-party and shadow ones, and to attach least-privilege permission profiles before launch. Microsoft keeps a unified agent registry in the Microsoft 365 admin center, and Agent Control at agentcontrol.dev applies centralized policies to a fleet at runtime. A company that cannot see its agents cannot govern them, so central discovery earns its price.

Kortix is an open-source CompanyOS — your agents, skills, company memory, and connectors in one git repo you own. Any model, your keys, self-hosted or managed cloud. Our answer to the same four jobs is to make the policy a line in that repository, in the same file as the agent it governs.

Where the rule lives decides what a reviewer can prove

Six months after an incident, three questions decide whether the governance holds up. Which change introduced the rule. Who approved that change. And what the rule actually said on the day the action ran. A console answers them from its own record, attached to an agent it discovered, read through its own interface. That is a genuine record, and console vendors export it.

A repository answers the same three questions from the artifact that produced the decision. git log -p kortix.yaml prints every version of the file, git blame names the commit and the person behind a line, and the change request that carried it holds the review and the approval. Nobody has to rebuild the policy from a second system, because the copy that runs is the copy the team read.

The difference surfaces in what can drift. A rule in a console governs the agent the console found, and it stays in that console when the agent's definition moves to another team's repository. A rule in the manifest travels with the agent block that enables it, since both are lines in the same file, merged in the same change. Widen a connector rule in a diff and the review sees a permission grow, next to the task that motivated it.

The control layer as a file in the repository

The manifest reference documents the shape, and this is a support project's control layer in full.

# yaml-language-server: $schema=https://kortix.com/schema/kortix.v3.schema.json
kortix_version: 3
default_agent: support

connectors:
  - slug: helpdesk
    provider: http
    base_url: https://helpdesk.example.com/api
    auth:
      type: bearer
    policy_sets:
      no-deletes:
        description: Ticket deletion never runs.
        policies:
          - match: "delete_*"
            action: block

agents:
  support:
    description: Answers help desk tickets.
    mode: primary
    prompt_file: agents/support.md
    permission:
      bash:
        "*": allow
        "git push *": ask
      edit: deny
    tools: [read, glob, grep, bash, edit]
    connectors: [helpdesk]
    policy_sets:
      helpdesk: no-deletes
    workspace: { project_repository: true }

Read it in four parts. default_agent names the agent a bare session starts as. The connector is declared once for the project, and its rule set blocks one pattern: a ticket deletion never runs, whoever asks. The agent block is the identity. bash runs by default, a git push waits for a person, edit is refused outright, and the tools list narrows what the agent can call at all. The last three entries attach the connector and its rule set, then give the session a checkout of the repository.

Three checks run on the file before it governs anything. kortix validate reads it against the v3 schema, kortix ship runs the same check before it pushes, and the merge re-runs the schema check, so an invalid manifest blocks the merge with MANIFEST_INVALID (the reference). Nothing merges itself: work reaches main through a change request a person approves, unless an admin granted the merge capability.

Two defaults keep this honest. An omitted permission is allow, and tools, permission and codemode are open by default in the schema, so a project that never writes the block has no gate at all. Approval gates you set. Off until you set them. Writing the block is where a team records a decision it has already made, in a form the next reviewer can read.

What a reviewer can ask for on the day of an incident

Approvals in Kortix are deliberately small. One approval covers one exact action, with the same connector, action, arguments and account, and it runs that action once. Change a detail and the approval is void. A held action expires when nobody decides within 24 hours, unless the project sets another time. There is no approve-everything-for-this-session switch, and an action that has to run unattended needs a rule that allows it (the guide).

The audit record answers the rest. Every action is recorded. Reading, exporting and streaming the audit log is an Enterprise feature. Recording itself is always on, a refused request is recorded too, and when an agent acts the log names the person it acted for. It never stores a key.

Sign-in and directory sync come from your identity provider, with SAML 2.0 single sign-on and SCIM 2.0 available on an Enterprise license. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

When a bolt-on control plane is the right buy

Our arrangement governs the agents that live in the repository, and that is a real limit. If a company runs agents from five vendors, plus agents its teams built on laptops, the inventory comes first. A product built to discover agents across an estate solves a job one repository cannot. A security team asked to inventory agents it never deployed should buy the inventory layer, and should not expect a manifest to substitute for it.

The two compose. Keep the rule for the agents you own beside those agents, and point an inventory tool at the rest. What a review needs is a rule a person can read at the moment of the decision, and on the agents you run, the manifest is that rule.

Start with the rule that would cost the most

Pick the action that would hurt most if an agent took it unsupervised, and write it into the manifest as a block or an ask. On a project you have not governed before, that one line is the control plane for that agent: reviewed in a diff, merged through a change request, and readable by whoever arrives next.

Two related reads: what a control plane still needs from a runtime, and where an agent's tool access actually begins.

Kortix is free to start and free to self-host.