03. Values and principles

New to the field? Start with what AI governance is.

The Thesis states eight values and six principles in one line each. This chapter expands them. The two are deliberately different kinds of thing, and the difference is what keeps them from being the same list told twice. A value is a preference: a trade-off, what we lean toward when we cannot have both; it is stated as an affirmation, and naming what we build toward also names what we build away from. A principle is a commitment to act: a rule of method, phrased as something we do, that holds regardless of preference. So the values name the artefacts and outcomes we build toward; the principles name how we work, and they carry no vocabulary borrowed from the values. Read the values to know which way to lean; read the principles to know what to do on Monday.

Not all of the values are new to AI. Governance as code (1), machine-readable evidence (5) and measured risk reduction (7) are inherited from GRC engineering, the parent discipline. Evals that fail the build (2) and agent identity and scope (4) are what AI forces us to add; the model that must be tested and the autonomous actor that must be bounded have no analogue in classic GRC.

These are the book’s own values and principles. The principle sets published by others are treated elsewhere: chapter 11 traces the published responsible-AI principle sets to artefacts, and chapter 22 has the OECD AI Principles mapped to the stack.

The eight values

Each value is stated as an affirmation: what we build toward, which by naming it also names what we build away from. The values-and-principles form follows the GRC Engineering Manifesto that is this book’s precedent¹.

1. Governance is code, not a document

A policy in a PDF is a statement of intent that a human must read, remember and apply. A policy as code is a control that executes: it evaluates a pull request, a deployment or a runtime call and returns a decision. The document describes the rule; the code is the rule, versioned in a repository, tested, and enforced without anyone remembering to. When the rule changes, you change one artefact and every enforcement point updates. When an auditor asks what the policy was on a given date, you show the commit.

This is not “delete all documents.” A policy still needs a human-readable statement of why it exists. The value is that the authoritative, enforced version is the executable one, and the prose is its documentation, not the other way around.

2. Evals fail builds; reviews only recommend

A review produces a recommendation; someone may act on it, later, or not. An eval produces a verdict with consequences: the model or agent passed or failed a defined test, and a failure blocks the release. In AI systems the most honest control is a test the system must pass, run automatically, whose result changes what happens next. We prefer controls that bite.

A review still has its place: for questions no test can settle. But when a property can be tested (a jailbreak resistance threshold, a PII-leakage bound, a tool-scope check), turning it into a review instead of an eval gate is a choice to be able to recommend but not to stop.

3. Evidence comes from runtime, not from a point-in-time attestation

An attestation says a control was in place when someone looked. Runtime evidence shows the control working continuously, from the system itself. AI systems change between reviews (a model is retrained, an agent gains a tool), so evidence gathered once decays immediately. We prefer evidence that is emitted as the system runs, so “is the control working?” is answered by live telemetry, not by a signature dated last quarter.

4. Every agent carries its own identity and scope

An agent acting on a shared service account or a static key is ungovernable: you cannot attribute its actions, revoke its access precisely, or bound what it may do. We prefer every non-human actor to have its own identity, an owner, and a scope of permitted actions, established before it is allowed to act. Identity is the precondition of accountability; scope is the precondition of containment. Chapter 23 builds both for agents, starting from identity and short-lived credentials.

5. Evidence is machine-readable or it is not evidence

Evidence a human must produce, format and file by hand does not scale and cannot be verified at speed. Machine-readable evidence (OSCAL, structured eval results, signed logs) can be queried, diffed, aggregated and checked automatically. We prefer evidence a machine can read, because the audit then becomes a query and the same evidence feeds continuous assurance rather than a one-off binder.

6. Tooling must be inspectable and composable

The point is not who built the tool or whether it is open source; it is whether you can see inside it. You cannot trust a verdict you cannot trace. Inspectable tooling lets you follow a decision to the rule that produced it, the input it saw and the evidence it emitted; composable tooling lets you wire that decision into your own pipeline rather than export into someone else’s. We prefer tooling whose reasoning and data path we can open, bought or built, because governance you cannot see inside is a control you cannot trust. One vendor’s comparison of the AI-governance platform category, published by a competitor in it, finds that most of the category “manages the program (inventories, assessments, framework mappings, evidence workflows) without any runtime data path”³; where that holds, the objection is not that the tooling is commercial but that its verdict cannot be audited.

This is a lean, not an absolute. Closed and commercial tools have a place, including capable platforms. But the default is tooling the team can inspect and compose, over a black box the team must take on faith.

7. Success is measured in realised risk reduction, not framework coverage

Mapping every control to NIST AI RMF and ISO 42001 proves you have read the frameworks; it does not prove any risk fell. We prefer to measure the thing itself: did the rate of the failure mode drop, did the blast radius shrink, did the incident get caught earlier? Coverage is an input; realised risk reduction is the outcome. A green mapping matrix over a broken control is theatre with extra steps².

8. Governance is owned with engineering, not enforced from outside

Governance that sits apart and grants or denies passage is a bottleneck engineers route around. Governance owned jointly with engineering, built into the paved path, adopted because it is the easiest way to ship, becomes part of how things are made. We prefer shared ownership: the governance function builds the tooling, engineering builds on it, and the gate is a stage in a pipeline both own, not a meeting one side dreads. Chapter 12 describes the governance culture that shared ownership depends on.

We still use the practices each value builds away from; we build toward the affirmation.

The six principles

Build the control at the earliest point it can block

Put every control where it can still stop the thing going wrong, and no later. The earliest place a risk can be caught is the cheapest to fix and the strongest place to enforce: catching it in the repository beats catching it in production, which beats explaining it to a regulator. So a control is sited at the first gate that can refuse the change: a policy in CI, an eval before deploy, an identity check at admission, a guardrail at the point of action. The commitment is about placement: whatever the control, it belongs at the earliest enforceable point, not bolted on at the end.

Give every control teeth

A control must be able to change what happens next: block a merge, fail a deploy, revoke access. Anything that can only inform a committee is a signal, and we say so rather than dress it up as a control. This is the commitment that turns an eval from research into a gate, a policy from a PDF into a check, a threshold from a dashboard number into a release blocker. When a property can be tested, turning it into a review instead of a gate is a choice to be able to recommend but not to stop, and we make that choice consciously or not at all.

The teeth are not the whole animal. A gate that can fail the build is necessary and not sufficient: an eval is point-in-time and sampling-bound, it can be gamed by tuning the model to the suite or the threshold to the model, and it catches regressions against known cases, not the novel attack the suite never imagined. So a control with teeth carries obligations of its own (its coverage measured, its cases maintained adversarially, its thresholds traced to named failure modes), and a passing gate obliges the runtime monitoring of layer 04, it does not replace it. A green gate treated as proof of safety is framework theatre with a faster pipeline.

Register and bound every actor before it acts

Nothing, human or non-human, gets to act until it has an owner, a declared scope and a way to be stopped. Autonomy on shared credentials is ungovernable by construction: you cannot attribute, contain or revoke what you cannot trace to an actor. So registration is a precondition, not a follow-up: every actor is enrolled, scoped and given a kill switch before it does anything on its own. Autonomy is earned by being governable, not granted by default.

Instrument the build to produce its own proof

Wire each control to emit its own record as it runs, so assurance falls out of the system instead of being assembled by hand before an audit. If demonstrating a control needs a screenshot, we have not finished building it. The commitment is to instrumentation: every gate, guardrail and check writes a structured, signed record as it fires, so the audit is a query and the same records drive continuous assurance and incident response (chapter 17 specifies the incident record).

Start from a named failure mode or a named harm

Design each control against a specific way the system fails or a specific harm it can do to a person, and start there, not from a framework checklist. Threat models (prompt injection, tool misuse, agent identity abuse, data exfiltration) and fundamental-rights impact assessments are the inputs to design, not paperwork produced afterward. If we cannot name the risk a control answers, we do not build it. Chapter 13 shows how to go about identifying risk sources, factors and stakeholders, and the harms atlas lists harms by level, each with the control that catches it.

Make the governed path the easiest path

Ship governance as tooling, templates and paved paths engineers adopt without asking permission (a policy library, a registry with an API, a gate they can run locally before they push), and measure adoption. The people governed are our users; the paved path has to be the fastest path or it will be routed around. If using the governance is harder than avoiding it, the governance is designed wrong, and we fix the product, not the people.

Maps to: the values and principles are realised through the five-layer stack (chapter 04) and the pattern catalogue (chapter 05); the failure modes they target are OWASP Top 10 for Agentic Applications; the assurance they demand maps to ISO/IEC 42001, NIST AI RMF and EU AI Act Arts. 9, 15, 55 and 72. Mappings are illustrative, not a claim of conformity.

Sources

1. [1] GRC Engineering Manifesto (values and principles precedent). grcengineering. ~2024. https://grc.engineering/ (verified: primary)
2. [2] “What is GRC Engineering” (Ayoub Fandi; “theatre with extra steps”). GRC Engineer. 2025. https://grcengineer.com/what-is-grc-engineering/ (verified: primary)
3. [3] “Best AI Governance Platforms in 2026: 14 Enterprise Vendors Compared” (vendor-published comparison of the 13 Magic Quadrant vendors plus its own product; most of the category “manages the program … without any runtime data path”). Kosmoy. 2026-07-10. https://www.kosmoy.com/resources/blog/best-ai-governance-platforms-2026/ (verified: secondary)
4. [4] Top 10 for Agentic Applications 2026. OWASP GenAI Security Project. 2025-12-09. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ (verified: primary)