Governance, Evidence, and the Legal Floor

Why this matters

An email arrives from Pip's payment processor. It is polite and short: "Please describe the controls you have in place over automated refunds issued by your support software." There is a deadline. Pip forwards it to Dev with one word: "Help?"

Dev could write a paragraph. A paragraph would say "we have guards and a human approves refunds," and the processor would write back with more questions. Instead Dev replies with four attachments: docs/governance-record.md, the last two red-team reports, the adversarial suite's pass rate from the latest release, and a month of logs/approval.jsonl summarized in a table. Each attachment points at something that runs. The processor reads them, marks the account reviewed, and stops asking. This lesson is about producing that reply before anyone asks for it.

1. Why a record

Everything you built in L6 and L7 lives in code, tests, and logs. That is where it belongs. But code does not explain itself to a processor, an auditor, an insurer, or the engineer who replaces Dev next spring. Memory fades. People leave. Files answer.

A governance record is one page, kept in the repository, that says who owns the agent, what it may do, how you know it is behaving, and what happens when it is not. It is not a policy document. Every line points at a file, a number, a person, or a date that exists.

2. NIST AI RMF in four headings

The NIST AI Risk Management Framework (NIST AI RMF) is a voluntary framework published by the US National Institute of Standards and Technology for managing the risks of AI systems. It has four functions, and each one is a question you can answer for Sprout.

• Govern. Who is accountable, what are the rules, and how do changes get made?
• Map. What is the system, who uses it, what can it touch, and what could go wrong?
• Measure. How do you know it is behaving right now?
• Manage. What do you do about the risks you found and the incidents that happen?

The course you are in maps onto those headings almost one to one. L1's threat model is Map. L5's red team and adversarial suite are Measure. L6's guards and L7's queue, kill switch, and runbook are Manage. Govern is the part nobody has written down yet.

3. The legal floor

The EU AI Act is the European Union's law for AI systems. It sorts uses of AI by risk. Some uses are banned. High-risk uses, such as systems that help decide who gets hired or who gets credit, carry heavy obligations: documentation, human oversight, record keeping, registration. Many everyday uses carry lighter duties, and the most relevant one for Sprout is a transparency obligation: people must be told that they are interacting with an AI system rather than a person.

A support agent for a plant shop most likely lands in that lighter group. So Sprout's floor is short: say it is an AI, do not pretend to be Maya, and keep enough records to show that. Which obligations apply, and when, depends on where Pip's operates, who its customers are, and how the law's guidance develops.

The floor is the minimum the law requires. It is not what you are aiming at. The goal is the spec: correct answers, no leaks, no refund outside policy, no one's order shown to anyone else, measured on every pull request. A team that hits the spec clears the floor without noticing. A team that aims only at the floor ships an agent that introduces itself honestly and then refunds Sam.

4. The evidence pack

The record says what is true. The evidence pack is the set of files that prove it. It is what you attach when someone asks, and it should regenerate from the repository and the logs without anyone assembling it by hand.

It lives in the repository, one dated folder per review. Raw logs stay where they are; the pack holds summaries so a reviewer never opens a 40,000-line file. A short script, run at the monthly review, copies the current documents and summarizes the last thirty days of logs/guard.jsonl and logs/approval.jsonl. If a file is missing, the pack is incomplete and the review notes why.

5. Supply chain

The supply chain of an agent is everything it depends on that you did not write. For a web app, that is mostly packages. For an agent, the list is longer, and each item is a place where someone else's mistake or intent becomes your incident.

• The model provider. The model behind Sprout is a versioned dependency. A new version can change how it responds to injection, in either direction. Pin the model version in config, and run the adversarial suite before moving to a new one.
• Tools and MCP servers. An MCP server is a program that exposes tools to a model over the Model Context Protocol, a standard way for models to discover and call tools. If Sprout's shipping lookup came from a third-party MCP server, whoever wrote that server decides what its tool results contain, and tool results are an entry point. Know who wrote each tool, what it can reach, and what it returns.
• Dependencies. Packages in package.json. Dependency pinning means locking each package to an exact version so an update cannot arrive silently. Pin, keep the lockfile, and run an audit on a schedule.
• Ingested documents. Anything you load into a search index or a memory store is a dependency on its author. Fernworks writes PDFs; Pip's reads them into search_care_guide. Nobody at Pip's reads them all.

6. Insufficient logging

The OWASP Top 10 for Agentic Applications is the community list of the ways agents get attacked or go wrong. The category left for last is insufficient logging, because it decides whether any of the others can be handled.

Without logs there is no evidence pack, because the summaries have nothing to summarize. There is no incident story, because you cannot reconstruct what the model read, what it requested, and what the guard decided. There is no red-team baseline, because you cannot tell whether this month's findings are new. The guard log in logs/guard.jsonl and the approval log in logs/approval.jsonl are the record's Measure section, written one line at a time.

{"t":"2026-07-18T14:02:11Z","guard":"tool","tool":"issue_refund","user":"jordan","decision":"queued","reason":"tier2","approval_id":"ap-3f9c"}

One line like that, next to the four before it, is the difference between the two stories.

7. The monthly review

A security review is a short, recurring meeting where the people who own the agent look at the evidence and update the record. Monthly is right for Sprout. The agenda is fixed so nothing is skipped:

1. New tools, entry points, or roles since last month. Does the threat model cover them?
2. Red-team findings. What did Rosa find, and does each finding have a test?
3. Suite changes. Cases added, cases removed and why, current pass rate.
4. Incidents. Timelines, what the runbook learned, whether the fix has a test.
5. Approval metrics. Volume, approval rate, timeouts, median time to decision. Watch for approver fatigue.
6. Supply chain. Model version, dependency audit, new documents ingested.
7. Record update. Edit docs/governance-record.md, regenerate the evidence pack, set the next date.

Summary

• A governance record is one page in the repository that answers who owns the agent, what it may do, how you know it is behaving, and what happens when it is not. Every line points at a file, a number, a person, or a date.
• The NIST AI RMF's four functions give the headings: Govern, Map, Measure, Manage. L1 fills Map, L5 fills Measure, L6 and L7 fill Manage, and Govern is what you write in this lesson.
• The EU AI Act sets a floor for an agent like Sprout, most likely a transparency duty to say it is an AI. The floor is not the goal; the spec is. None of this is legal advice.
• The evidence pack is the dated folder of files that prove the record: threat model, playbook, red-team reports, suite results, guard and approval log summaries, incident reports. It regenerates from what already exists.
• The supply chain includes the model version, tools and MCP servers, packages, and ingested documents like Fernworks PDFs. Insufficient logging is the category that decides whether any incident can be understood, and the monthly review is where the record, the pack, and the open risks get updated.