Governance claims are easy to make. The interesting question is: what actually happens, mechanically, when an agent takes an action? Where does the control sit? Who or what evaluates it? What runs if the action is approved? And what record is produced?
Ethosure’s architecture answers all of those questions with a single coherent design. Every agent action that touches a governed codebase or toolchain passes through the same five deterministic steps. The evaluation is always deterministic. The record is always produced. There are no exceptions.
Step 1: Intercept
The enforcement layer sits at the boundary between the agent and the things it is trying to do. Depending on how Ethosure is deployed, this boundary is enforced through Git hooks (catching changes to code before they land), agent tool-use hooks (catching tool calls made by a coding or task agent), or an MCP proxy (intercepting requests routed through the Model Context Protocol).
Interception happens before execution. An agent’s action does not proceed until the enforcement layer has processed it. This is the foundational design choice that distinguishes a control from a monitor.
The MCP server also provides an advisory channel: agents can query the enforcement layer – using tools like `policy_check_command` and `policy_check_edit` – before attempting an action. The advisory channel does not replace blocking enforcement; it helps well-behaved agents avoid blocked actions in the first place.
Step 2: Evaluate
Evaluation has two distinct components.
The fact collector is written in Go. It gathers structural facts about the action: the abstract syntax tree of code being written (parsed with Tree-sitter), the shell command and its arguments, the file paths involved. Facts are deterministic – the same input always produces the same facts.
The policy evaluator uses CEL (Common Expression Language) to evaluate facts against the compiled policy bundle. CEL is deterministic, pure, and side-effect-free. It does not call a model, use embeddings, or make probabilistic judgments. The same facts evaluated against the same policy always produce the same result. This property is what makes Ethosure’s decisions reproducible and auditable.
Probabilistic approaches are explicitly prohibited from the enforcement path. They exist in the system – for code-intelligence search – but never as the source of a control decision.
Step 3: Decide
Evaluation produces exactly one of four dispositions: Allow, Transform, Escalate, or Block. Every action resolves cleanly. The system is fail-closed: malformed inputs are denied, indeterminate evaluations are blocked, and bypass attempts through alternative paths are treated as enforcement failures.
Step 4: Sandbox
An action that receives an Allow or Transform disposition does not execute without constraint. It runs inside a runtime sandbox using Linux namespace isolation. The repository is mounted read-only by default. Write access is restricted to declared paths. Network access is disconnected for offline tools. CPU, memory, and time are bounded by cgroup limits. Syscall access is restricted with seccomp profiles.
Approval and confinement are separate properties. 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.
Step 5: Record
Every action that passes through the enforcement layer produces a structured finding in the evidence ledger, regardless of its disposition. The finding is written in SARIF format, includes the policy rule and skill reference that drove the decision, and carries remediation metadata for blocked or transformed actions.
Events are stored as append-only JSONL and feed into a rebuildable DuckDB store. Every finding is traceable back to the specific trace, file, symbol, policy rule, and SARIF result that produced it. The ledger is not modified after the fact – it is an authoritative record of what the enforcement layer decided at each moment.
This record satisfies audit requirements mapped to NIST AI Risk Management Framework categories, ISO/IEC 42001 documentation requirements, and the EU AI Act’s technical documentation obligations.
How it deploys
Ethosure supports three primary deployment shapes:
- Git hooks – the enforcement layer runs as Git pre-commit and pre-push hooks, catching policy violations before code lands in the repository.
- Agent tool-use hooks – the enforcement layer intercepts tool calls at the moment of execution.
- MCP proxy – the enforcement layer acts as a proxy between the agent and the Model Context Protocol.
A fourth shape – the Agent Proxy – is in early development. It provides an opt-in runtime boundary intercepting outbound provider requests, inbound responses, local tool calls, and file operations, recording body-free evidence including token usage and payload hashes without exposing content.
All deployment shapes are local-first. There is no required hosted backend. The enforcement layer runs in your environment, keeping sensitive agent activity data on your infrastructure.
