# Governance in the Code Path — Mnemom Research

```json
{"@context":"https://schema.org","@type":"Article","headline":"Governance in the Code Path","name":"Governance in the Code Path","description":"Every AI governance product on the market monitors what agents did. Today we're shipping one that governs what they can do \u2014 a policy engine in the request pipeline, trust recovery when configuration errors aren't behavioral failures, predictive intelligence for multi-agent teams, and on-chain anchoring for the proof chain.","url":"https://www.mnemom.ai/fr/blog/mnemom-research/governance-in-the-code-path","inLanguage":"fr-FR","datePublished":"2026-02-26","dateModified":"2026-02-26","author":{"@type":"Organization","name":"Mnemom Research","url":"https://www.mnemom.ai/fr/blog/mnemom-research"},"image":"https://www.mnemom.ai/api/og-image?type=blog&eyebrow=DISPATCHES&chip=Mnemom+Research+%C2%B7+6+min&author=Mnemom+Research&title=Governance+in+the+Code+Path&subtitle=Every+AI+governance+product+on+the+market+monitors+what+agents+did.+Today+we%27re+shipping+one+that+governs+what+they+can+do+%E2%80%94+a+policy+engine+in+the+request+pipeline%2C+trust+recovery+when+configuration+errors+aren%27t+behavioral+failures%2C+predictive+intelligence+for+multi-agent+teams%2C+and+on-chain+anchoring+for+the+proof+chain.","publisher":{"@id":"https://www.mnemom.ai#organization"},"keywords":["policy","governance","clpi","trust-recovery","intelligence","on-chain"]}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.mnemom.ai/fr"},{"@type":"ListItem","position":2,"name":"Dispatches","item":"https://www.mnemom.ai/fr/blog"},{"@type":"ListItem","position":3,"name":"Mnemom Research","item":"https://www.mnemom.ai/fr/blog/mnemom-research"},{"@type":"ListItem","position":4,"name":"Governance in the Code Path","item":"https://www.mnemom.ai/fr/blog/mnemom-research/governance-in-the-code-path"}]}
```

[← Mnemom Research](/fr/blog/mnemom-research)

# Governance in the Code Path

![Mnemom Research](/images/mnemom_hero.webp)

Mnemom Research

26 février 2026

This post was published before the May 2026 vocabulary alignment (ADR-042). Where you see "Smoltbot," read "Mnemom." Where you see "XFD," read "Safe House." The technical claims still hold; the names have evolved as the system matured.

_Mnemom Research | February 2026_

* * *

Every AI agent governance product on the market works the same way. Monitor what the agent did. Log it. Flag anomalies. Show someone a dashboard. The human reads the dashboard. The human decides what to do.

This is the equivalent of a bank that records every transaction but has no fraud rules. You know that something bad happened. You just can't stop it from happening.

Today we're shipping Card Lifecycle & Policy Intelligence — CLPI. It puts governance directly into the code path: the actual request pipeline that every agent action flows through. Policy evaluation happens _before_ the action executes, not after.

## The Semantic Gap

Alignment cards declare what an agent is allowed to do in human terms:

```json
"bounded_actions": ["inference", "read", "write", "web_fetch"]
```

Actual tool names are specific:

```
mcp__browser__navigate, execute_python_code, search_web, read_file
```

There's a gap between what the card declares and what the tools do. Until today, that gap was bridged by interpretation — the observer would analyze traces and infer whether the agent's tool usage matched its card declarations. Sometimes the inference was wrong. Configuration errors looked like behavioral violations. The trust score took the hit regardless.

CLPI eliminates the gap with a policy DSL. A YAML file that maps semantic capabilities to concrete tool patterns:

```yaml
capability_mappings:
  web_browsing:
    tools:
      - "mcp__browser__*"
    card_actions:
      - "web_fetch"
      - "web_search"

  file_reading:
    tools:
      - "mcp__filesystem__read*"
      - "mcp__filesystem__list*"
    card_actions:
      - "read_file"

forbidden:
  - pattern: "mcp__filesystem__delete*"
    reason: "File deletion not permitted"
    severity: "critical"
  - pattern: "mcp__shell__*"
    reason: "Shell execution not permitted"
    severity: "high"

defaults:
  unmapped_tool_action: "warn"
  grace_period_hours: 24
```

This isn't a configuration file. It's a governance contract. The card declares intent. The policy enforces it.

## Three Checkpoints, One Engine

The policy engine evaluates the same rules at three points in the agent lifecycle:

**CI/CD (before deployment).** The CLI command `mnemom policy evaluate` validates that an agent's tool manifest matches its alignment card plus policy. Fails the build on mismatch. This runs in any CI system via `npx @mnemom/smoltbot policy evaluate --card card.json --tools manifest.json`.

**Gateway (before each action).** The gateway extracts tool names from the API request body — Anthropic, OpenAI, and Gemini formats are all supported — and evaluates them against the policy in real time. Three modes: `enforce` (reject with 403), `warn` (log and forward), `off` (skip). The response carries an `X-Policy-Verdict` header so downstream systems know the evaluation result. Policy fetch is parallelized with quota resolution, adding zero latency to the hot path.

**Observer (after execution).** Retroactive verification against traces. This is where the system distinguishes _card gaps_ (a tool the agent uses that isn't in its card — a configuration error) from _real violations_ (a tool the agent uses that's forbidden). The distinction matters for what comes next.

Same engine. Same rules. No drift between what CI checks, what the gateway enforces, and what the observer verifies. One policy definition governs the entire lifecycle.

## Trust Recovery

Before CLPI, this scenario was common: you add a new MCP tool to your agent, the agent starts using it, the observer flags `UNBOUNDED_ACTION` violations because the alignment card doesn't declare the new capability, and the Mnemom Trust Rating drops. The violations were real — but the root cause was a configuration error, not a behavioral failure. Fixing the card didn't fix the score. The damage was permanent.

CLPI changes this. When the observer detects a capability violation, it now classifies it: _card gap_ or _behavior gap_. A card gap means the tool isn't in the alignment card but isn't forbidden by policy — it's a missing declaration, not a dangerous action.

Fix the card, and the system reclassifies the violations:

```
POST /v1/agents/{agent_id}/reclassify
```

Reclassification triggers a cascade. The scoring engine recomputes the Mnemom Trust Rating with the violations excluded. Trust graph propagation recalculates downstream agents that were penalized by transitive trust decay — BFS traversal, three hops, capped at 50 agents. If the affected violations were in a proven session, the prover re-issues the proof (the original remains valid but is marked superseded). OTel events emit `gen_ai.safety.reclassification` with before and after scores.

This sounds like a bookkeeping exercise. It's not. It's the difference between a system people trust and one they fight. A governance system that punishes configuration errors the same way it punishes behavioral violations will train operators to stop updating their agents — or stop using the system. Trust recovery makes the system _honest_.

Grace periods smooth the curve further. When the gateway sees a tool it hasn't seen before, it gets a configurable window (default 24 hours) before the tool becomes a violation. This gives operators time to update their alignment card after deploying new capabilities, without tripping enforcement during the rollout.

## The Intelligence Layer

Detection tells you what happened. Prediction tells you what _will_ happen. Recommendation tells you what to do about it.

CLPI's intelligence layer builds on N-way coherence analysis — given a team of agents, the system computes a matrix showing exactly where their values align and diverge. That's been live since V2. The intelligence layer extends it:

**Fault line extraction.** From the coherence matrix, extract specific value dimensions where agents conflict. "These two agents have opposing escalation policies for data access." Concrete, actionable, attributed.

```
POST /v1/teams/fault-lines
```

**Predictive risk forecast.** Map fault lines to a task context and predict failure modes. "68% chance of escalation conflict on data queries. Primary drivers: agent-a4c prefers to escalate, agent-b8f prefers to resolve autonomously."

```
POST /v1/teams/forecast
```

**Policy recommendation.** Given the team composition, task context, and fault lines, generate a `policy.yaml` that mitigates the predicted risks. Ready to deploy. Backed by a STARK proof covering the full derivation chain — fault lines, forecast, recommendation, guardrail merge, and enforcement verdicts — in a 5-step SP1 guest program.

```
POST /v1/teams/recommend-policy
```

**Transaction-scoped guardrails.** The recommended policy can be applied as a temporary overlay for a specific multi-agent transaction. The gateway enforces a three-layer merge: org policy + agent policy + transaction guardrails. The guardrails inject conscience values into AIP for the duration of the interaction, then expire automatically. No permanent policy changes required.

This is the consulting product embedded in the API. Instead of hiring a team to audit your agent fleet, you call an endpoint and get a governance configuration backed by cryptographic proof of how it was derived.

## On-Chain Anchoring

The proof chain now extends to a public ledger.

Agent reputation scores are publishable to a `MnemoReputationRegistry` on Base L2 — an ERC-8004-aligned contract that stores scores (0–1000) with timestamps and on-chain verification. A second contract, `MnemoMerkleAnchor`, anchors Merkle roots of the complete proof tree at configurable intervals. Any party can verify a score publication or Merkle inclusion against the on-chain state without trusting Mnemom infrastructure.

The dashboard shows an "anchored on-chain" indicator with Basescan transaction links. Both contracts are open source with 20 Foundry tests.

On-chain anchoring is opt-in and additive. It doesn't change how proofs work or how scores are computed. It adds an external, immutable verification point for customers and counterparties who need it.

## What Changed

Before today, Mnemom could tell you what your agents did and whether they could be trusted. After today, Mnemom governs what your agents _can do_ — with the same cryptographic rigor applied to the governance layer itself.

Monitoring becomes enforcement. Observation becomes policy. Dashboards become code. And the proof chain extends from the zkVM to a public ledger that anyone can verify.

* * *

Card Lifecycle & Policy Intelligence is live today. Start with `mnemom policy init` to generate a starter policy, or call `POST /v1/policies/evaluate` to test your agents against existing alignment cards.

[Policy Management Guide](https://docs.mnemom.ai/guides/policy-management) · [Policy DSL Specification](https://docs.mnemom.ai/specifications/policy-dsl) · [Intelligence API](https://docs.mnemom.ai/api-reference/intelligence-overview) · [Trust Recovery Guide](https://docs.mnemom.ai/guides/trust-recovery) · [On-Chain Verification](https://docs.mnemom.ai/guides/on-chain-verification)

* * *

_Mnemom builds alignment and integrity infrastructure for autonomous agents. AAP and AIP are open source and available on [npm](https://www.npmjs.com/package/@mnemom/agent-alignment-protocol) and [PyPI](https://pypi.org/project/agent-alignment-protocol/)._

_GitHub: [github.com/mnemom](https://github.com/mnemom) · Docs: [docs.mnemom.ai](https://docs.mnemom.ai)_

#policy#governance#clpi#trust-recovery#intelligence#on-chain

### Stay in the loop

New dispatches and product updates, no spam.

Company website (leave blank)

Subscribe

### Prêt à vérifier vos agents ?

Voir en directVoir les tarifsNous contacter

[![Mnemom Research](/images/mnemom_hero.webp)

Mnemom Research

Tous les articles →



](/fr/blog/mnemom-research)

---
_Source: /fr/blog/mnemom-research/governance-in-the-code-path/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents_
