What is self-hosted agent governance?

Self-hosted agent governance means running AI agents on your own infrastructure, connected to your own tools, governed by your own rules, to automate the steps of your software delivery lifecycle. It is self-hosted infrastructure you own and control.

The agents in these pipelines handle tasks like pull request creation, code review, test execution, and deployment. The governance layer defines how those agents compose into end-to-end workflows, what humans need to approve, and what can run autonomously.

The key word is governance. Governance gives you bounded autonomy: agents take on the steps you grant them, humans approve at every gate you place, and a full audit trail records every decision.

Who needs this?

Engineering teams at organizations of 50 to 1,000 engineers who are already using coding agents (Cursor, Copilot, Claude Code) and need governance before they can expand usage. The agents are already in the codebase. The missing piece is control.

DevX and Platform Engineering teams building the internal infrastructure for AI-powered development.
Engineering leadership who need to show auditors that AI-generated code follows the same review and approval processes as human-written code.
Security and compliance teams in regulated industries (defense, finance, healthcare, government) who need data sovereignty, air-gap capability, and full audit trails.
Organizations that want to scale their use of AI coding agents without scaling their risk.

What governance requires

Governance is a set of controls that work together to answer three questions: who can do what, what did they do, and who approved it.

SSO/SAML

Single sign-on with SAML 2.0 integration. Centralizes authentication through your identity provider, eliminates password sprawl, and enforces session policies across the organization.

Why it matters: SOC 2, ISO 27001, and most enterprise security frameworks require centralized authentication. A tool that runs AI agents on your codebase without SSO creates a credential-management blind spot.

RBAC

Role-based access control defines who can create pipelines, who can approve changes, who can view audit logs, and who can modify governance policies.

Why it matters: Not everyone on the team should have the same permissions. A junior engineer should not be able to approve their own code changes. RBAC enforces separation of duties without manual oversight.

Audit log

An append-only record of significant governance events such as run starts, agent dispatches, gate decisions, configuration changes, and access events. The run record separately captures run-level snapshots, reported outputs, timing, and final artifacts. Community records these facts; Team adds the audit viewer, chain verification, exports, signed evidence packs, and the compliance evidence index.

Why it matters: When something goes wrong at 2am, you need to know what happened, who approved it, and whether the process was followed. An audit trail is the difference between a root-cause analysis and a guessing game.

HITL gates

Human-in-the-loop approval gates that pause pipeline execution until a designated human approves the next step. Configurable per pipeline, per step, per change-class.

Why it matters: Autonomous agents that write code without human review are a liability. HITL gates let you start with full human oversight and gradually reduce it as agents earn trust.

Cost controls

Per-agent token budgets hard-stop a run that overspends. A pipeline spend circuit breaker trips on rolling monthly spend and pauses that pipeline's triggers until an admin resets it. An admin-only, audited org-wide pause (the kill switch) stops new trigger-initiated runs across the organization.

Why it matters: LLM API costs are metered. An agent that loops unexpectedly can burn hundreds of dollars in hours. Cost controls cap the damage and alert you before the invoice arrives.

Capability scopes

Granular permissions that define what each agent can do: which repos it can access, which actions it can take, which environments it can deploy to.

Why it matters: An agent that can read your code should not automatically be able to push to production. Capability scopes enforce least-privilege access for every agent in the pipeline.

Policy-as-code guardrails

Guardrail configuration is versioned, hashed YAML. You propose a change, review the diff, and apply it through a pull request. Each run's snapshot pins the guardrail version it ran under, with drift detection.

Why it matters: Guardrail changes get the same review as code changes, and the run record shows which rules applied to each run.

Why self-host?

Self-hosting keeps your code, your prompts, your model configurations, and your audit trail on infrastructure you control. No telemetry by default. No telemetry by default, opt-in only. With default settings and no connectors configured, Farna Control makes no external network calls.

For regulated industries, self-hosting keeps code and audit records on infrastructure you control, which many security reviews ask about. Your own assessment still applies.

Self-hosting also means no vendor lock-in. If the vendor changes pricing, changes direction, or shuts down, your infrastructure keeps running. You own the platform and the data on it.

See also: Self-hosted agent governance for a deeper look at running governed agents on your own infrastructure.

How it differs from adjacent categories

vs CI/CD tools (GitHub Actions, GitLab CI)

CI/CD tools run deterministic workflows: if condition X, do action Y. They execute scripts and pipelines with no reasoning. Agent governance adds agents that can read code, understand context, make decisions, and take actions within governance constraints. GitLab now layers its own governed software factory over GitLab CI, which governs inside GitLab rather than across the other tools a change touches.

vs general automation (n8n, Zapier)

General automation connects SaaS tools and runs business workflows. Agent governance composes AI agents into software delivery pipelines with typed schemas and governance gates. The two categories serve different problems.

vs LLM app builders (Dify, Flowise)

LLM app builders create AI applications for end users: chatbots, document Q&A, conversational agents. Agent governance governs the agents that write, review, and ship code. Different direction, different audience, different governance requirements.

vs AI coding assistants (Copilot, Cursor)

AI coding assistants help individual engineers write code faster. Agent governance governs how agents interact across the entire delivery pipeline: who can create PRs, who reviews, who approves, who deploys. The assistant is a tool. The governance layer is the process.

Frequently asked questions

What is agent governance?

Agent governance is the set of controls that determine what AI agents can do, where humans need to approve, and what can run autonomously. It covers access control, audit trails, approval gates, cost limits, and bounded autonomy. Without governance, AI agents are an uncontrolled liability.

Why self-host instead of using a cloud service?

Self-hosting keeps your code, your prompts, your model configurations, and your audit trail on infrastructure you control. With default settings and no connectors configured, Farna Control makes no external network calls. For organizations in defense, finance, healthcare, or government, self-hosting keeps code and audit records on infrastructure you control, which many security reviews ask about.

Where does agent code actually run, and who controls it?

You choose per environment profile. The local provider runs agent commands as subprocesses on the Farna Control host with no sandboxing, which suits evaluation and solo development. The runner_docker provider gives each workspace an ephemeral hardened container, and you can point it at a Docker engine you own, including a remote host on your network. The e2b provider gives each run an isolated sandbox. Pipelines are portable across providers.

What infrastructure does Farna Control need?

Docker Compose is the supported way to run Farna Control. The production configuration brings up the API, the frontend, queue workers, PostgreSQL 16, and Redis, and it needs Docker Compose v2.20 or later. A native Linux install is available for workstations and evaluation.

Does any data leave my network?

Farna Control has no telemetry by default, opt-in only, and it is air-gap capable. Model calls go only to the providers you configure, so pointing a model backend at a local endpoint such as Ollama, vLLM, or LocalAI keeps inference inside your network. Connectors call the tools you connect, so those calls leave your network when the tool is external.

How does Farna Control differ from CI/CD tools like GitHub Actions?

GitHub Actions runs deterministic workflows: if condition X, do action Y. Farna Control runs AI agents that can reason about code, make decisions, and take actions within governance constraints. The two are complementary. Farna Control handles the parts of the SDLC where an agent needs to think; GitHub Actions handles the parts where a workflow needs to execute.

How does Farna Control differ from general automation tools like n8n?

n8n connects everything to everything: CRM to invoicing, Slack to Jira, database to spreadsheet. Farna Control composes AI agents into typed pipelines that automate software delivery. n8n is a Swiss Army knife. Farna Control is a governed agent runtime. The use cases overlap only at the level of "both automate things."

How does Farna Control differ from LLM app builders like Dify?

Dify builds AI applications for end users: chatbots, document Q&A, conversational agents. Farna Control governs the AI agents that write, review, and ship your code. Dify faces outward toward your customers. Farna Control faces inward toward your SDLC.

What does the pricing include?

The Team tier is a flat annual license per organization. Current pricing is on /control/pricing. There is no per-seat, no per-run, no usage metering. It includes SSO/SAML, SCIM provisioning, RBAC, the audit viewer, chain verification, audit exports, signed evidence packs for offline verification, the compliance evidence index, HITL gates, bounded autonomy, and capability scopes. Community still captures run-level evidence and significant governance events, and exposes run data through the API. Token budgets, the pipeline spend circuit breaker, and the org-wide pause are in every tier; Team adds organization and team spend limits, a budget overview, and a cost breakdown. LLM API costs are separate and under your control.

Is Farna Control open source?

Farna Control is source-available under the Business Source License (BUSL). The farnalabs/farna-control repository is public and inspectable. The license restricts the field of use (you cannot offer Farna Control as a competing hosted service) but does not restrict internal use. It is not OSI-approved open source.

Can I try Farna Control before buying?

The Community edition is free and self-hosted. You can evaluate the full platform without talking to anyone. The Team tier is a self-service purchase with an offline signed license key.

The complete, canonical FAQ is at /control/docs/faq.

Try Farna Control

Farna Control is self-hosted. You can evaluate it without talking to anyone.

Community edition (free) Team tier (price on /control/pricing)

Questions? Open a discussion on GitHub.