Skip to main content

Self-hosted agent governance

What it is, who needs it, and how to evaluate governance requirements for AI agents in your software delivery pipeline.

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 immutable record of every action taken by every agent and every human. Hash-chained and tamper-evident. Covers pipeline executions, gate decisions, configuration changes, and access events.

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 data leaves your network unless you explicitly send it.

For organizations in regulated industries, self-hosting is often a compliance requirement. SOC 2, ISO 27001, and sector-specific frameworks (FedRAMP, HIPAA, GDPR) expect data sovereignty. A cloud-hosted SaaS that sends your code to a third-party server creates audit and compliance complications that self-hosting avoids entirely.

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. No data has to leave your network. For organizations in defense, finance, healthcare, or government, self-hosting is often a compliance requirement.
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 Modulo 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 Modulo need?
Docker Compose is the supported way to run Modulo. 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?
Modulo sends no telemetry, 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 Modulo differ from CI/CD tools like GitHub Actions?
GitHub Actions runs deterministic workflows: if condition X, do action Y. Modulo runs AI agents that can reason about code, make decisions, and take actions within governance constraints. The two are complementary. Modulo 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 Modulo differ from general automation tools like n8n?
n8n connects everything to everything: CRM to invoicing, Slack to Jira, database to spreadsheet. Modulo composes AI agents into typed pipelines that automate software delivery. n8n is a Swiss Army knife. Modulo is a governed agent runtime. The use cases overlap only at the level of "both automate things."
How does Modulo differ from LLM app builders like Dify?
Dify builds AI applications for end users: chatbots, document Q&A, conversational agents. Modulo governs the AI agents that write, review, and ship your code. Dify faces outward toward your customers. Modulo faces inward toward your SDLC.
What does the pricing include?
The Team tier costs $6,000/year pre-GA founding price, rising to $12,000/year list from v1.0. No per-seat, no per-run, no usage metering. It includes SSO/SAML, SCIM provisioning, RBAC, audit logging, HITL gates, bounded autonomy, and capability scopes. 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 Modulo open source?
Modulo is source-available under the Business Source License (BUSL). The farnalabs/modulo repository is public and inspectable. The license restricts the field of use (you cannot offer Modulo as a competing hosted service) but does not restrict internal use. It is not OSI-approved open source.
Can I try Modulo 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 /docs/faq.

Try Modulo

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

Questions? Open a discussion on GitHub.