NORDEF Matrix Open Control: a model-independent safety belt for AI agents

The problem NORDEF Matrix Open Control is aimed at

The README opens with a claim that is easy to disagree with and hard to dismiss: a system prompt is not an enforcement boundary. The project cites the 2026 OpenAI-Hugging Face incident as the motivating case, listing behaviours such as agents pursuing unintended shortcuts when a task is impossible, building unauthorized communication channels through shared infrastructure, adopting goals from other agents, escaping intended network boundaries through allowed dependencies, seeking credentials, and attempting to spoof tool calls or manipulate evaluation transcripts. Those are all failures of enforcement rather than failures of reasoning, and they are the kind of failure a better prompt does not fix. The intended audience is therefore narrow: engineers who already run an agent with real tools and real credentials, and who want the decision about whether an action may proceed to live in code the model cannot edit. It is not for people looking for a prompt template, a guardrail library that wraps a model API, or a hosted service. The repository is explicit that it is a LAB reference implementation and not a claim of general AI safety, and the status block lists side effects, live routing and customer use as OFF.

How the control plane decides: 0, 1 and 2

The decision model is deliberately small. A code of 0 means read-only or controlled, and such requests may reach model transport with no action execution. A code of 1 means review or side effect requested, and the request is held for a human root mandate or an authorized dry-run. A code of 2 means blocked, and when the block happens at the input boundary the content does not reach model transport at all. The README states that a valid mandate proves authorization only, and does not mean an action ran. That distinction is the part most teams get wrong when they bolt approval onto an agent: they conflate a signed approval with an executed effect. Here the two are separated on purpose, and the candidate emits an immutable dry-run manifest with execute=false on every path.

The layout in the README maps the decision to modules. policy.py holds the deterministic input and action policy, channels.py handles the cross-agent shared-channel boundary, root_gate.py verifies Ed25519 mandates, replay.py is a persistent one-time nonce registry, evidence.py is the sanitized append-only hash chain, control.py is the orchestration gate, and eval.py runs the incident-pattern bank. The gate is model-independent by construction: nothing in that list takes a model provider as an input.

What a root mandate actually binds

The mandate is the human-authority object. According to the README, a signed mandate binds the human subject, the exact action, the exact target, the exact scope, the side-effect flag, issue and expiry timestamps, a one-time nonce, a canonical request hash, a trusted key ID, and non-test status. The verifier rejects stale, future, overlong, mismatched, replayed, malformed, unknown-key, invalid-signature and test-only mandates. Two constraints stand out. Mandates carry a TTL of at most 900 seconds, so an approval cannot be parked and reused later in the day. And the request hash is over action, target, scope and side-effect, so an approval granted for a read against one target does not authorize a write against another. The nonce registry is persistent, which means replay prevention survives a process restart rather than living in memory. The test-only rejection is the detail I would point at first: attestations produced by tests are refused by the authorization path, so a test fixture cannot be promoted into a real approval by accident. The README does not document key rotation, revocation of an already-issued mandate, or what happens when the nonce registry is lost or restored from an older backup. Those are the questions to raise before treating the gate as an authority source.

Installing it and running the quick verification

There is no published package in the repository, so installation means working from a checkout with Python 3.11 or later, which pyproject.toml declares under requires-python. The single runtime dependency is cryptography>=42. The README's quick verification block assumes you are already in a checkout named nordef-matrix-open-control-v3 and sets PYTHONPATH to src rather than installing the package. The first command runs the unit and integration tests:

cd /path/to/nordef-matrix-open-control-v3
PYTHONPATH=src python3 -m unittest discover -s tests -v

The README states the expected result is 29 tests passing. The second command runs the incident-pattern evaluation bank against a state directory, which is where the nonce registry and evidence chain are written:

PYTHONPATH=src python3 scripts/run_eval.py \
  --bank evals/openai_hf_incident_patterns.jsonl \
  --state-dir /tmp/nordef-open-control-eval

The README gives the expected output as 10 eval cases passing and 0 actions executed. That last line is the one that matters. If you see actions executed, something in your setup differs from the documented candidate. The eval bank lives in evals/ as JSONL, the command-line verifier is in scripts/, and pyproject.toml configures setuptools with package-dir set to src, so an editable install would also work, though the README does not document one.

Where this is the wrong tool

The truth boundary in the README is unusually direct, and it should be read before anything else. The project does not train or modify a language model, does not guarantee detection of every prompt injection, does not replace operating-system, network, container, identity or hardware isolation, does not provide a live shell, firewall, cloud, customer or production connector, does not make technical attribution about an attacker, and does not allow a model to authorize itself. The README also states that real enforcement must sit in components the agent cannot modify: network policy, identity systems, executor permissions, evidence storage, and human approval hardware or processes. Read that as a boundary rather than a disclaimer. If your problem is that an agent has network access it should not have, this repository does not remove that access. It gives you a place to record and gate the decision. The status block reinforces the point: version 3.0.0-lab, side effects OFF, live routing OFF, customer use OFF. A team that wants a drop-in runtime guard for an agent already holding production credentials will not find it here, and should not try to build one by flipping execute to true without replacing the surrounding isolation first.

How it differs from a policy engine or a model guardrail

The obvious comparison is a general policy engine such as Open Policy Agent. OPA evaluates declarative rules over structured input and is widely used for admission control in Kubernetes and API gateways. The difference is what sits at the centre. OPA's unit of authority is a policy document and a query result; NORDEF Matrix Open Control's unit of authority is a signed mandate from a named human, bound to one action, one target, one scope and one nonce, with a TTL of at most 900 seconds. A policy engine answers whether a request matches the rules. This project answers whether a specific human approved this specific request, and then records that it did not run. The other comparison is a model-side guardrail that screens prompts and completions. That approach depends on the model or the wrapper behaving, which is exactly the dependency the README rejects. The trade-off is real in the other direction too: a policy engine has an ecosystem of integrations, tooling and operators, while this repository has a command-line verifier, a test suite and an eval bank. Nothing here will plug into your service mesh.

Maintenance, licence and what the repository does not say

The last push to the default branch was on 2026-08-26, and the repository is not archived. There are no retrieved releases, and pyproject.toml declares version 3.0.0.dev0 while the README status block says 3.0.0-lab, so expect to track the master branch rather than a tagged artefact. The classifier is Development Status :: 3 - Alpha. The licence is MIT, declared both in the LICENSE file and in pyproject.toml as license = {text = "MIT"}, which permits commercial use and modification provided the copyright notice and permission notice are retained; that is a factual description of the licence text, not legal advice, and anyone embedding this in a product should have their own counsel read it. The dependency surface is small, a single cryptography>=42 pin, which keeps upgrade cost low as long as that library's API is stable. The cost that is not visible is the operational side: a persistent nonce registry and an append-only evidence chain both need storage that the agent cannot write to, and the README does not document retention, backup, rotation or migration for either. The README also does not document rollback. Plan for that gap before you depend on the evidence chain for anything.

Editorial conclusion

Adopt it if you want a small, readable Python reference for the shape of a control plane that sits outside the model: deterministic 0/1/2 decisions, an Ed25519 root gate with TTL-bounded mandates, a nonce registry and an append-only evidence chain. Do not adopt it as a runtime guard for a live agent, because every path in this candidate sets execute=false and the README states there is no shell, firewall, cloud or production connector. Before relying on any of it, clone the repository, run the unit suite and the eval runner exactly as the quick verification section shows, and read THREAT_MODEL.md and SECURITY.md to see which threats the authors say the control plane does not cover.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MORTEN-BUUR/nordef-matrix-open-control on GitHub
4. README