Policy-Only AI Governance Tools vs Runtime Enforcement: Which Produces SR 26-2 Evidence?

Design evidence and operation evidence are different artifacts

The NIST AI Risk Management Framework draws a useful line. Its Govern function says policies, processes, procedures and practices for mapping, measuring and managing AI risk should be "in place, transparent, and implemented effectively." Having a policy and implementing it are two separate claims, and each needs its own proof.

The same framework defines validation as confirmation, through objective evidence, that requirements for a specific intended use have been fulfilled. The emphasis is on evidence that a requirement was met, not on a statement that it exists.

For risk leaders, this gives a practical test for any artifact: does it describe what should happen, or does it record what did happen? A policy library entry, a model inventory row, a signed attestation and a completed approval workflow all describe intent, ownership and accountability. A record that says policy version X was applied to this request at this time, and the result was a block, describes operation.

This page does not restate SR 26-2 text. It gives a way to classify artifacts so that each can be matched to the specific requests your examiner or internal audit function issues.

What each approach can hand an examiner

Policy-only tools are legitimate for documentation, inventory and accountability, and they do that work well. The comparison below concerns one question: what artifact shows a control operated on a specific AI action.

• Policy and its version history: Policy-only: yes, this is the core output. Runtime enforcement: records which policy version applied to each decision.
• AI system inventory and ownership: Policy-only: yes. Runtime enforcement: not its purpose; it shows traffic it sees, not a complete inventory of intended systems.
• Attestations and workflow approvals: Policy-only: yes. Runtime enforcement: human approval escalations are recorded for individual actions, not for organizational sign-off.
• Record of a decision on one interaction: Policy-only: no, it records intent rather than application. Runtime enforcement: yes, if the decision is made and recorded in the execution path.
• Record of a decision on one tool call: Policy-only: no. Runtime enforcement: yes, when the enforcement point sees agent and MCP tool-call traffic.
• Exception handling evidence: Policy-only: documents the exception process. Runtime enforcement: records which actions were blocked, redacted, rate limited or escalated, and the human decision.

Where a control sits determines what it can record

A control outside the execution path can record intended rules. It can show that a policy was authored, approved and communicated. It cannot show that the policy was applied to a given request, because it never saw the request.

A control inside the execution path sits between the caller and the action. It evaluates each proposed action against policy before the action takes effect, and it can record the decision tied to that action. The record relates to one event rather than to a general rule. A recent conference presentation on runtime execution governance for agentic AI describes a similar idea: a policy enforcement point applies a decision before commit, and evidence is bound to a specific proposal. That is one proposed model, not a standard, but the distinction it draws is useful.

Timing matters as much as location. Enforced at runtime, a decision changes the outcome: a request is allowed, redacted, blocked, rate limited or held for human approval. Reviewed after the fact, a record can describe what happened but cannot have prevented it. Auditors will treat these differently.

Coverage is the other architectural question. Agent tool calls and MCP server calls are separate traffic from model calls. A tool that sees only model prompts and responses leaves the actions agents take through tools outside its records.

Trussed as an example of enforcement in the execution path

Trussed is a runtime control and evidence layer, not an AI governance platform. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. The actions are allow, redact, block, rate limit and escalate for human approval. Enforcement is applied to individual interactions and tool calls, and the evidence is generated by those enforcement decisions rather than assembled afterward.

That evidence is continuous and audit-ready, and it is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. In production, it has run for more than 18 months in a regulated enterprise at 99.95% uptime on live traffic, with 100+ models under one policy plane and more than 30 GB of audit evidence generated per day.

The scope limits are specific. Trussed does not provide business transaction identity or transaction-level governance across tasks and agents. It does not provide model provenance, model lineage or dataset provenance. It does not trace agentic workflows end to end. Its evidence covers what happened at the interaction and tool-call level, and it does not replace policy authoring, inventory or attestation records.

Choosing policy-only, runtime enforcement, or both

Start with an artifact inventory. Tag each record you can produce today as design evidence (policy text, inventory, attestation, approval) or operation evidence (a decision on a specific interaction or tool call). Then list what your examiner or internal audit function asks for and mark where an operation record is expected but only a design record exists.

If your requests are mainly about accountability, ownership and documented requirements, a policy-only tool may be sufficient. If they include showing what an AI system was permitted to do and what it did, you need records produced where the action occurs. In that case runtime enforcement closes the gap, and policy-only tooling remains the home for the policies being enforced.

The combination is common for good reason. Policy and inventory tools define intent and ownership. Runtime enforcement applies that intent and records each decision. Connect both to your existing governance and risk controls so that evidence sits in one reviewable trail rather than in separate silos.