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?
Why self-host instead of using a cloud service?
Where does agent code actually run, and who controls it?
What infrastructure does Modulo need?
Does any data leave my network?
How does Modulo differ from CI/CD tools like GitHub Actions?
How does Modulo differ from general automation tools like n8n?
How does Modulo differ from LLM app builders like Dify?
What does the pricing include?
Is Modulo open source?
Can I try Modulo before buying?
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.