The hardest part of AI agent governance is not writing a policy document. It is building infrastructure that enforces the policy – at runtime, deterministically, on every action, without being bypassable – and producing a tamper-evident record while doing it. Most organizations trying to solve the AI governance problem discover that this is the part they cannot easily build themselves.

Ethosure’s enforcement core is built on a coding-ethos project.  It carries the OpenSSF Best Practices Silver badge and is tracking towards Gold. It is not a prototype or a roadmap item – it already runs and it is developed by one of the Ethosure founders, Patrick Audley.

The control plane: CEL + Go evaluators

The control plane is where enforcement decisions are made.

Fact collection is done in Go. For code changes, Tree-sitter parses the code into an abstract syntax tree and extracts structural facts: what constructs are present, what patterns exist, what the change actually does at a semantic level. For shell commands, the parser extracts the command name, arguments, and target paths. These facts are objective – they describe what the action is.

Policy evaluation uses CEL (Common Expression Language). CEL is deterministic, side-effect-free, and pure – it takes facts and policy rules as inputs and returns a result. It does not call a model. It does not use embeddings. It does not make probabilistic judgments. As the coding-ethos project documentation puts it: “CEL remains pure and deterministic.” The same facts evaluated against the same policy always produce the same result.

Probabilistic and embedding-based approaches are explicitly prohibited from the enforcement path. Embeddings exist in the system for code-intelligence search – helping agents find relevant prior work and understand the codebase – but they are never the source of a control decision. A search that helps an agent find context may be probabilistic; a control that blocks or allows an action may not.

See also  Allow, Transform, Escalate, Block: The Four Things That Can Happen to an Agent Action

The control plane resolves every action to one of four dispositions: Allow, Transform, Escalate, or Block. Malformed inputs are denied, indeterminate evaluations are blocked, and bypass attempts through alternative paths are treated as enforcement failures.

The data plane: runtime sandbox

The data plane operates after the control plane issues a decision. An action that is Allowed or Transformed does not execute without constraint – it executes inside a runtime sandbox that confines what the approved process can actually touch.

The sandbox uses Linux namespace isolation, giving the executing process a constrained view of the system. The repository and `.git` directory are mounted read-only. Write access is available only to paths the action was explicitly authorized to modify. Network access is disconnected for offline tools. CPU, memory, and time are bounded by cgroup limits. Syscall access is restricted by seccomp profiles.

This two-layer design reflects a critical insight: approval and confinement are not the same thing. A policy-compliant action might still do unexpected things if given unlimited access. The sandbox ensures that even an approved action operates under least-privilege – it can do what it was authorized to do, and nothing more.

Why this is the hardest part to build

Organizations that attempt to build enforcement infrastructure for AI agents typically discover that the difficulty is not conceptual – the design is understandable. The difficulty is in the rigor of implementation.

Fail-closed behavior sounds simple until you are testing it against adversarial inputs. A bypass attempt that uses a subprocess to invoke Git without the hook, or sets an environment variable to skip enforcement, must be caught. Coding-ethos includes explicit red-team tests for bypass behavior, treating bypass attempts as test cases rather than edge cases.

Supply chain integrity is a second dimension of rigor. The enforcement core uses SPDX SBOMs, GitHub and PyPI artifact attestations, offline `.intoto.jsonl` bundles, SHA-256 checksums, and PyPI Trusted Publishing. Static analysis is applied continuously: CodeQL, OSV-Scanner, Zizmor, OpenSSF Scorecard, golangci-lint, Ruff, mypy, Pyright, Pylint, and Bandit. The project dogfoods its own enforcement – coding-ethos enforces its own rules on its own repository.

See also  Build vs. Buy: Why the Enforcement Layer Is the Part You Don't Build Yourself

The OpenSSF Best Practices Silver badge represents an independently assessed level of security, testing, and development practice maturity. Tracking toward Gold represents continued investment in the rigor that enterprise buyers and security auditors require.

Why this matters for the enterprise buyer

The question a buyer should ask about any AI governance vendor is not “do you have a governance product?” but “do you own the enforcement core, and is it production-grade?”

The enforcement core is not assembled from off-the-shelf components. The combination of deterministic CEL evaluation, Go-based fact collection, fail-closed behavior, runtime sandboxing, and tamper-evident evidence production is a purpose-built system. It takes time to build correctly, and the rigor of the implementation is visible in the project’s security posture, supply chain practices, and test coverage for adversarial behavior.

Gartner’s 2025 Market Guide for AI Governance Platforms describes “guardian agents” as the blend of AI governance and AI runtime inspection and enforcement. The term reflects the recognition that enforcement at runtime is a distinct capability – not a feature of an existing governance platform, but the core of a new category. Ethosure owns that enforcement core. It already runs.

Subscribe to Ethosure's Newsletter to get monthly updates on AI Governance

We don’t spam! Read our privacy policy for more info.