The build-versus-buy question comes up in every technology investment cycle. For AI agent governance, the question is particularly fraught because the problem is novel enough that many organizations are uncertain what a good solution looks like – and because the temptation to build is strong when internal teams can see, in principle, how one might be constructed.
Ethosure’s view is direct: there are parts of the AI governance stack that organizations should absolutely own. The enforcement layer is not one of them.
What the stack actually looks like
AI agent governance has at least three distinct layers with different build-versus-buy economics.
The policy layer – what your agents are allowed to do, what data they can access, what actions they can take – is inherently organizational. It reflects your risk appetite, your regulatory obligations, and your business context. No vendor can write this policy for you. This is the layer you own.
The compliance mapping layer – how internal policies map to NIST AI RMF, ISO/IEC 42001, EU AI Act, and OSFI AGILE requirements – is partially shared. The frameworks are external; the mapping is organizational. Templates and tooling help, but expertise is required.
The enforcement layer – the technical mechanism that intercepts agent actions, evaluates them against policy in real time, makes deterministic decisions, sandboxes approved actions, and produces tamper-evident audit evidence – is infrastructure. Infrastructure is the category you almost never build yourself.
The case for building: why it sounds attractive
The internal build case is superficially compelling: engineers understand the technology, the problem seems well-defined in principle, the organization can tailor the solution to its specific stack, and there is no vendor dependency. Each of these points is real. None survives contact with the actual implementation challenge.
What the enforcement layer actually requires
The Gartner Market Guide for AI Governance Platforms (November 2025) defined the guardian-agent category precisely because the enforcement layer is harder to build than it appears. Consider what a production-grade implementation requires:
Determinism. The enforcement decision must be the same for the same action and policy every time, independent of the AI model, the prompt, or the time of day. This requires a policy evaluation engine that is formally deterministic – not probabilistic, not embedding-based. Building a CEL (Common Expression Language) evaluator correctly, with proper edge-case handling and indeterminate-state semantics, is non-trivial.
Fail-closed behavior. When the policy evaluation encounters an unexpected input, the correct response is to deny – not allow, not return an error the agent can interpret as permission. Building fail-closed semantics correctly, with red-team testing of bypass attempts (alternative execution paths, hook-skip flags, subprocess indirection), is a security engineering challenge most organizations are not equipped to handle rigorously.
Tamper-evident logging. An append-only evidence ledger that cannot be altered after the fact, that links every decision to the specific policy version that governed it, and that produces SARIF or structured output auditors can work with – this is not a simple logging problem.
Supply chain security. The enforcement layer itself must be trustworthy. An enforcement tool with an insecure build pipeline or unverified dependencies creates a new attack surface. Meeting OpenSSF Best Practices standards, maintaining SBOMs, and implementing artifact attestations requires sustained engineering investment.
Runtime sandboxing. Constraining what an approved process can actually touch – Linux namespace isolation, read-only filesystem access, network controls, cgroup limits – requires low-level systems expertise and ongoing maintenance.
The real cost of building
The IBM Cost of a Data Breach 2025 found the average financial-services breach cost $5.56 million. Omdia projects AI partner services at $276 billion by 2030, a significant share going to organizations remediating governance failures that occurred while they were building enforcement infrastructure rather than deploying it.
The internal build option is not just expensive in engineering time; it is expensive in risk exposure *during the build period*. An organization spending twelve months building an enforcement layer runs agents without governance for twelve months. The expected cost of that exposure – discounted breach probability times breach cost plus regulatory penalty risk under the EU AI Act and OSFI AGILE – almost always exceeds the cost of deploying production-ready enforcement tooling immediately.
What you should own vs. what you should buy
The principled division: own your policy, own your compliance mapping, own your evidence review process. Buy the enforcement infrastructure.
Ethosure’s architecture is built on the `coding-ethos` open-source project (AGPLv3 / commercial license, OpenSSF Best Practices Silver badge, project #12737, tracking Gold). The enforcement core – the CEL evaluator, the fail-closed runtime, the tamper-evident ledger, the runtime sandbox, the SARIF output – was built by specialists and is maintained, red-teamed, and supply-chain-audited as a dedicated engineering investment. Organizations deploying Ethosure own and write their policies; Ethosure provides the infrastructure that enforces them.
This division respects actual comparative advantage. Organizations know their business context, risk appetite, and regulatory obligations. Ethosure knows how to build enforcement infrastructure that does not leak, does not bypass, and does not fail open.
The build-versus-buy question for the enforcement layer is not really a question. It is the part you don’t build yourself.
