What agent governance is, and why an LLM can't do it by reading code

What is agent governance?

Agent governance is a deterministic audit of an autonomous system's source, config and deployment — identity, authority, isolation, evidence, supply chain, oversight and documentation — verified by reading named files, not by asking a model whether the code looks safe.

Why can't a language model judging code replace this?

Because a model's verdict is a probability, not a rule: it can flag a documented example key as leaked or miss a real one, and it gives no fixed file-and-line reason a regulator can re-check.

What proves the difference, rather than just asserting it?

Two adversarial fixture trees, tricky_clean and tricky_dirty, look alike to a keyword scan; run through aga.py today, tricky_clean scores 3 controls PASS, tricky_dirty scores 0 — decided by file location and quoting, not wording.

What exactly told the two fixtures apart?

Three checks: id.no_secrets read a .gitignore before calling a credential a leak, sc.safe_deploy required that a destructive command sit outside quotes, and ev.refusals_logged looked for an actual refusal path — distinctions a keyword match alone cannot make.

Does this mean an LLM has no role in agent governance?

It has one: reading this evidence and explaining it in plain language. What it cannot do is stand in for the file-and-line check itself, because its judgment is not reproducible the way a fixed rule reading a fixed file is.

The worked proof: one keyword pattern, opposite verdicts

Three of the 27 controls, run against both fixture trees today, show the mechanism directly: the same class of keyword (a credential-shaped string, the phrase "DROP TABLE", the phrase "refuse") appears in both trees, and the verdict still comes out opposite — because the rule reads file location, quoting and .gitignore coverage, not word resemblance.

Source: /root/apexclaw-audit/aga_fixtures/tricky_clean and /root/apexclaw-audit/aga_fixtures/tricky_dirty, re-scored today with aga_cli.py against aga.py (AGA/1.0). Full run: tricky_clean scores 12.0/100 (3 PASS, 0 PARTIAL, 22 FAIL, 2 UNKNOWN), with its Identity family at 42.9%, Supply Chain at 21.4% and Evidence at 18.8%; tricky_dirty scores 0.0/100 (0 PASS, 0 PARTIAL, 25 FAIL, 2 UNKNOWN), 0% in all 7 families.

Why a keyword or resemblance judgment fails here specifically

A model asked "does this file contain a leaked secret" is being asked to judge shape: does this string look like a key. AKIAIOSFODNN7EXAMPLE has the exact shape of a real AWS access key id — that is the point of AWS publishing it as a test vector. rm -rf /var/lib/apt/lists/* has the same first four characters as the single most destructive shell command that exists. A rule that reads shape alone cannot separate these without also reading context a keyword match doesn't carry: is this string inside a quoted blocklist, is this path covered by a .gitignore, does the path end in a real directory or a bare root. aga.py encodes exactly those three pieces of context as code, not as a prompt, so the same input produces the same output every time it is run — which is what a durable record under EU AI Act Art.12 requires, and what a probability distribution over tokens does not guarantee.

Primary standards cited on this page: OWASP Agentic Top 10, NIST AI RMF, ISO/IEC 42001, EU AI Act.