Portfolio reference implementation discussed throughout this piece (trust-layer-agent) is built on synthetic IAM and CloudTrail fixtures and public NIST compliance documentation. Not affiliated with any actual federal program or agency. Views and architectural choices are my own.
Most enterprise AI programs are one audit question away from a problem they cannot answer.
The models work. The pipelines run. The demos hold up under scrutiny. Then someone asks a harder question.
Why was this action allowed? What evidence supported it? Where was the decision constrained?
The answer is often scattered across trace logs, prompts, application code, and service boundaries instead of being enforced by the architecture itself.
That may be sufficient when AI informs decisions. It is insufficient once AI begins executing workflows on behalf of its users.
Beyond Traditional Model Governance
On April 17, 2026, the OCC, Federal Reserve, and FDIC issued revised supervisory guidance on model risk management (SR 26-2), replacing SR 11-7 after fifteen years. The guidance recognizes that generative and agentic AI introduce characteristics that extend beyond traditional statistical model governance and require institutions to apply appropriate risk management practices as these technologies evolve.
Model validation was developed to evaluate datasets, statistical behavior, and predictive performance. It was never intended to govern systems that plan, invoke tools, cross trust boundaries, and execute multi-step workflows.
Extending those principles to agentic systems is an architectural challenge. The controls have to exist in the execution path itself.
Why Prompting Is Not Enough
An agentic system can behave correctly at every individual step and still produce an outcome no one authorized. It retrieves the right evidence. It calls the right tools. It generates a plausible assessment. Then it submits because nothing in its design required it to stop.
A prompt can influence model behavior. It cannot constrain system behavior. When the stakes involve regulatory submissions, compliance evidence, or other consequential enterprise decisions, that distinction matters.
Enforcement by Design
The trust-layer-agent is a reference implementation of what execution-time enforcement looks like for a federal compliance workflow.
The agent collects audit evidence for NIST 800-53 access control requirements, assesses sufficiency, drafts a cited compliance assessment, and then suspends while waiting for explicit human approval before anything is submitted.
Five nodes. One approval gate. One execution path, and it cannot continue without human approval.
Three architectural decisions make the difference between prompting an agent and governing one.
A trust ledger, not a configuration file. Every tool the agent may invoke is registered before execution with an explicit autonomy class, allowed actions, prohibited actions, and invocation limits. Tools outside the ledger are implicitly denied. The agent cannot invent capabilities it was never granted.
Enforcement at every boundary, not just the output. Two checkpoints surround every tool invocation. The pre-call gate validates authorization. The post-call gate validates evidence lineage before anything enters the agent’s reasoning state. Prompt injection intercepted at the evidence layer never reaches the model.
A state machine that cannot be reasoned around by the model. The submission path is structurally unreachable until a human reviewer issues an approval token. This is not a reminder embedded in a prompt. It is an execution constraint enforced by the workflow itself.
Evidence Over Claims
Every architectural claim is backed by a passing test.
The evaluation suite covers nineteen scenarios across three categories: happy path, failure modes, and adversarial behavior.
The critical scenario, FM-005, attempts to reach the drafting node without sufficient evidence. The state machine blocks the transition in every execution. That is not a prompt instruction. It is a structural property of the workflow.
The adversarial suite verifies that prompt injection delivered through retrieved evidence is intercepted before it reaches reasoning state, that fabricated approval tokens cannot bypass the approval gate, and that an LLM judge identifies errors in a deliberately flawed assessment without being told what to look for.
Trust is established by what the architecture allows the system to do.
The framework is the deliverable. The agent is the proof it works.
Reference implementation: The Trust Layer for Enterprise Agentic AI
Related reading: Beyond Retrieval: Architecting the Trust Layer for Enterprise AI — governed retrieval architecture that feeds the agentic layer.