AI agent management on an open-source platform

What AI agent management means

AI agent management is the work of running software agents inside an organization while keeping control of what they touch, what they spend, and what they change. It comes down to four questions. What is each agent allowed to reach? Where do the credentials it uses live? How do you watch the work while it happens? How does finished work reach the systems the rest of the company depends on?

Generic write-ups on the topic stop at the dashboard: pick an agent, give it a role, check the logs. The hard part is none of that. It is making the four answers enforceable, so a misconfigured agent fails closed instead of failing loud.

Kortix, the open-source AI Operating System, is the working example on this page. Agents, skills, memory, and connectors live in one git repo you own, and the management model is files in that repo plus a short list of platform settings.

Permissions: scope what each agent may touch

Kortix starts from one grant record. Per-resource permissions for people and agents. Roles, groups, and an audit trail.

An assignment binds one principal to one role at one scope. A principal is a person, a group, or a service account, which is an agent's identity. The scope is the whole account or one project, and an object assignment can narrow it further to a single agent, skill, secret, app, or trigger. Agents are closed by default: a member reaches an agent only when an assignment names them, one of their groups, or everyone in the project.

Agents carry a second binding on top of their role. The agents: block in kortix.yaml lists, per agent, which connectors it may call, which secrets it receives, which skills it may load, and which project permissions it may exercise. A session can only do what both bindings allow. The role that counts is the agent's own service-account role, its ceiling, not the role of whoever started the session, so an agent launched by an owner gains nothing the manifest did not grant. One permission, project.credentials.issue, is human-only and never reaches an agent.

v2 manifests are deny-by-default: a grant you omit resolves to none. You list what each agent needs, and nothing else passes.

The governance half of one agent, from the Kortix manifest reference:

agents:  release-bot:    file: agents/release-bot.md    connectors: [github]    kortix_permissions: [project.gitops.push]    secrets: [GITHUB_AGENT_TOKEN]

This agent may call the GitHub connector, receive one secret, and push to the repository. Its behavior and system prompt live in agents/release-bot.md; the manifest block is governance only.

Secrets: where agent credentials live

Credentials never live in the repo. kortix.yaml declares secret names and grants. Secret values never appear in the repo; they live in the platform, and secrets are encrypted at rest with a key per project.

Each secret carries an exposure setting that answers one question: can agent code read the real value? Environment is the default exposure: the session receives the value as a plain environment variable, which is what a credential the agent must compute with needs, such as a database connection string or a signing key. Egress-enforced is experimental: the sandbox holds a handle, and Kortix substitutes the real value outside the sandbox, only on approved HTTPS hosts. An echoed value comes back as [REDACTED]. The third exposure, none, keeps the value out of the sandbox entirely.

Connector credentials are brokered server-side and never enter the machine.

Delivery is scoped twice. A session receives a secret only when the person who started it and the agent's grant both allow it. On top of the grant, each secret has a "Who can use it" audience: everyone in the project by default, only you, or specific people or groups.

Monitoring: watch the session, read the diff

One isolated sandbox per session: each session has its own isolated machine and branch, so one agent's work never collides with another's.

While a session runs, you watch it live and steer it, from the web app, from Slack, or from a terminal. The record you keep afterward lives in the repo itself. Agents, skills, and memory are files, so every change to an agent or a skill is a diff you can read like any code review.

Kortix also writes an audit log. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan.

The review gate: how work lands

Session work reaches main through a change request. Merge is default-deny for agents.

The path, from the Kortix docs overview:

project (git repo + kortix.yaml)   └─ session ──> isolated sandbox on branch "<uuid>"                     └─ agent commits + pushes                           └─ change request ──> merge ──> default branch

A session can never merge a change request it opened itself. When your process wants agents to merge other agents' work, an admin grants project.gitops.merge to the agent's service account, and the self-merge rule still holds.

The gate is yours to tune. Approval gates you set. Off until you set them. Connector policies map tool patterns to Allow, Ask, or Block. Set Ask on the step that matters: the agent pauses before the call, a person approves or denies it, and the session resumes.

Config changes pass the same gate. A manifest, agents/, skills/, or OpenCode config edit applies only after a change request merges to main. An agent can edit its own configuration on its session branch and propose the change. A person approves it.

What this adds up to

A management model you can enforce beats one you can describe. In Kortix, the scope is a grant in a file, the credential is brokered or encrypted, the watch is a live session plus a diff, and the gate is a change request. If a control ever feels abstract, open the repo: the grants, the agent definitions, and the memory are all text you can grep.

Where to go next on this site: the orchestration page covers how sessions, triggers, and channels coordinate the work, and the self-hosting guide covers running the whole platform on your own server. The references behind the access model, the manifest, and secrets live in the Kortix docs; Read the docs to go deeper, and the Kortix blog carries the longer case for running agents on a platform you own.