Ask a financial institution’s chief information security officer whether they are comfortable routing AI agent governance decisions through a cloud service operated by a third party, and the answer will usually be no – or at minimum, a long conversation about data residency, vendor risk, and regulatory compliance. Ask the same question about a defense contractor, a healthcare organization, or a government agency, and the conversation gets longer still.
Ethosure and its open-source coding-ethos engine are designed from the ground up to run entirely on your own infrastructure. No hosted backend. No cloud dependency. No governance data leaving your environment. This “local-first” design is not a limitation – it is a deliberate architectural choice with significant consequences for data residency, vendor risk, and the kinds of environments where Ethosure can be deployed.
What local-first means
Local-first means that all enforcement, all policy evaluation, and all evidence storage happen within the organization’s own infrastructure – typically on the developer’s workstation, the CI runner, or an internal server. There is no external service that receives policy queries, stores enforcement decisions, or processes agent traffic.
With Ethosure:
- The compiled policy bundle (`policy-bundle.json`) is a file in the repository’s `.git/coding-ethos-hooks/policy/` directory.
- The CEL evaluators run as local Go binaries.
- The runtime sandbox uses native Linux kernel features – namespaces, Landlock, cgroups – with no cloud management plane.
- The code-intelligence store is a DuckDB file at `.coding-ethos/code-intel.duckdb` within the repository.
- The MCP server runs as a local process (`bin/coding-ethos-run mcp`).
- The evidence ledger (JSONL log) is stored in the repository’s `.coding-ethos/` directory.
None of these components call home. There is no telemetry to Ethosure, no policy synchronization with a cloud service, no analytics pipeline sending enforcement data to a third party.
Why data residency matters
Data residency is the requirement that certain data must be stored and processed within a specific geographic jurisdiction. This requirement arises from:
- Regulatory frameworks: the EU’s GDPR, Canada’s PIPEDA, the EU AI Act, and sector-specific regulations in financial services and healthcare often impose residency requirements on data related to business operations and regulated activities.
- National security considerations: government and defense organizations may have requirements that certain data never leave specific classified or domestically operated environments.
- Contractual obligations: enterprise contracts often include data residency clauses from customers who are themselves subject to residency requirements.
When an AI governance system sends enforcement decisions or agent activity data to a cloud service, it creates a data flow that may violate these requirements. The question “where does our AI governance data live?” has a simple answer in a local-first design: here, in our infrastructure, under our control.
Sovereign AI: the broader context
“Sovereign AI” has become a shorthand for a cluster of related concerns: that an organization’s AI capabilities – not just the data, but the models, the governance controls, and the infrastructure – should remain within its own jurisdiction and control. The Omdia Sovereign AI Primer identifies data residency as a primary concern for enterprises evaluating agentic AI deployment.
Ethosure’s local-first design addresses this at the governance layer. The enforcement core runs on the organization’s hardware, reads policy from the organization’s repository, and stores evidence in the organization’s storage. Even in a hybrid scenario where the AI model itself runs through a cloud provider, the governance layer – which intercepts and evaluates agent actions – remains on-premises.
No hosted backend does not mean no external tools
Local-first does not mean closed. coding-ethos integrates with:
- GitHub Actions: for CI enforcement and SARIF upload to code-scanning.
- PyPI and other package repositories: for installing the tool itself.
- External AI providers: the Agent Proxy routes provider traffic, but does not require those providers to know about coding-ethos governance.
The distinction is between the enforcement decision path (local) and optional integrations (external, at the organization’s discretion). The decision “allow or block this action” never requires a round trip to an external service. Integrations add value (CI visibility, package distribution) without creating a governance dependency.
Deployment shapes
coding-ethos’s local-first nature supports multiple deployment shapes, all without a hosted backend:
Developer workstation: the standard deployment. Install with `make install`, install hooks with `make install-hooks`, run the MCP server locally with `bin/coding-ethos-run mcp`. Everything runs on the developer’s machine.
CI runner: the same hooks and enforcement run in GitHub Actions, Jenkins, or any other CI environment. The policy bundle is compiled from source; the evidence is stored in the CI workspace or uploaded as an artifact.
Air-gapped environments: because coding-ethos requires no network access for its enforcement operations, it can run in environments that have no internet connectivity – a significant advantage for classified or high-security deployments.
Agent proxy sidecar: as the Agent Proxy feature matures, it will support deployment as a sidecar process alongside the AI agent, intercepting traffic locally without requiring a network-adjacent service.
The commercial licensing path
Organizations that cannot use the AGPLv3 open-source license (which requires that modifications be shared) can license coding-ethos under a commercial license from Blackcat Informatics Inc. The commercial license covers proprietary deployments while retaining all the local-first properties. Ethosure’s commercial offering is built on this foundation.
For regulated organizations, the combination of local-first enforcement, commercial licensing, and OpenSSF Silver badge-quality supply-chain practices addresses the three common objections to using open-source software in regulated environments: it runs in our infrastructure, it is commercially licensed, and its provenance is verifiable.
