SOLUTIONSStart with one risk domain.
Most institutions begin where the pain is newest and expand from there. The context layer does not change between domains, so the second one is configuration rather than another implementation.
The agents nobody approved are running.
A business unit stands one up with a vendor copilot. A year later it is still calling production systems on credentials nobody has reviewed, and the person who built it has changed roles twice.
The agent you want in production is stuck.
Risk asks a reasonable question: show me what it did, and what it was permitted to do. Without a trace of tool calls checked against a policy, the answer is a design document. The approval never comes, and eventually the business stops asking for it.
Nobody can attribute the spend.
Finance does not ask what AI costs in total. They ask what a single use case cost, which department owns that number, and what came back for it. An enterprise invoice answers none of the three.
Every LLM, prompt, MCP connection, and agent, with the data each one touches and a named owner attached. Discovered, not self-reported.
Trace a use case to the exact control that breached, across the LLM, prompt, agent, and data source involved. Raise it as a finding with an owner, and stop the agent at its policy boundary.
Over 40 controls across hallucination, security, identity, and data, executed against live behavior and scored against every NIST AI RMF domain.
Tokens and spend attributed to the workflow that incurred them, in real time, so each department sees its own consumption against budget.
Hallucination and output
- Groundedness against cited source
- Citation validity and reachability
- Output schema conformance
Security
- Prompt injection detection
- Tool call allowlist enforcement
- Secret and credential leakage
Identity and access
- Agent identity attestation
- Privilege scope verification
- Human approval gate on privileged actions
Data
- Restricted data in prompt or output
- Retrieval limited to approved sources
- Data residency boundary
The inventory is a spreadsheet with a date on it.
Models arrive from SAS, from notebooks, from vendors, and from whatever the last acquisition was running. The inventory gets manually reconciled. Between reconciliations, the true count is an estimate.
Documentation describes the model as it was.
A validation document captures a model when risk committee initially approved. Since then the variables are adjusted and algorithm was adjusted based on performance data. The validation documentation is stale.
Vendor models are your responsibility and someone else's black box.
Credit and capital decisions run on third-party models. SR 26-2 is explicit that relying on a vendor does not transfer responsibility for model risk, so you owe a conceptual understanding and risk-based monitoring of something you did not build.
One inventory across in-house, acquired, and third-party models, built from what is deployed rather than what was reported.
Metadata syncs from SAS, documents from your file systems. Semantic search across both returns an answer with a citation and a confidence score.
Statistical checks on input variables before a model scores, so drift is caught at the input instead of inferred from the output two quarters later.
Score distribution tracked over time with the business impact attached, so a shift in output reads as a shift in decisions.
Identity
- Owner and validator
- Risk tier and business use
- Approval status and expiry
- Change history
Inputs
- Critical data elements
- Source systems and lineage
- Transformations applied
- Quality thresholds and breaches
Documentation
- Development documentation
- Validation findings
- Stated limitations and approved use
- Assumptions and their basis
Performance
- Score distribution over time
- Population stability
- Override rate
- Decision and portfolio impact
Read from model development platforms
Identity, risk tier, algorithm, owner, deployment source, primary features, decision threshold, and regulatory scope on a single record, with the last-updated stamp that tells a validator whether they are looking at the current model or last quarter's write-up.
The catalog the model sits in, with ownership named
Entities, attributes, models, and documents for the portfolio, each with a business owner, data steward, risk owner, and technical owner. Questions are answered against this catalog's own contents, which is what makes an answer citable rather than plausible.
Nobody can say where a number came from.
A field on a regulatory report traces back through several systems and transformations written by someone who has since left. Answering where it came from takes a week and produces a diagram that nobody fully trusts.
Ownership is assumed, not assigned.
On paper every critical element has an owner. In practice the owner is whichever team most recently complained about the field, and when quality breaks the escalation goes to a distribution list.
Quality is measured after the damage.
Checks run overnight, or in a dashboard nobody opens, or downstream of the model that already scored on the bad input. By the time a number looks wrong on a report, business decisions were made weeks ago.
Attribute-level lineage across the data supply chain, with transformations summarized for the business rather than rendered as a graph only the data team can read.
CDEs identified, tiered, and tied to the reports, models, and controls that depend on them, so criticality is derived from use rather than asserted.
Checks run at the point of consumption, before a model scores or a report publishes, not on a nightly job whose failures nobody reads.
A named owner on every critical element, notified when their data breaks rather than when a finding lands months later.
Provenance
- Source system and extraction path
- Transformations applied
- Refresh cadence and last load
- Reconciliation to source
Definition
- Business definition
- Approved use and restrictions
- Criticality tier
- Policies that govern it
Quality
- Completeness and validity
- Range and distribution thresholds
- Referential integrity
- Breach history
Consumption
- Models that use it
- Reports it appears on
- Controls that depend on it
- Decisions affected downstream
Lineage across every hop, with the authoritative source marked
The end-to-end path for a decisioning pipeline, hop by hop, showing system, application, and storage at each step, with the attributes carried and the transformation applied. The authoritative source is marked, so a disagreement about a number has somewhere to end.
Quality measured against the attribute's own usual range
Completeness, uniqueness, and missing rates per attribute, trended daily against the range that attribute normally holds rather than a single global threshold. A dip below the floor is flagged where it happened, not inferred later from a downstream number.
The library grew by addition.
Every exam finding, every acquisition, every new product added a document. Nothing was ever removed. You now hold overlapping policies saying slightly different things, and the one people follow is whichever they were last shown in training.
Nothing traces a policy to the rule behind it.
Ask which policy implements a given regulatory requirement and the answer comes from institutional memory. Ask the reverse, which requirements a policy actually satisfies, and frequently there is no answer at all.
Change management is a project, not a process.
A rule changes. Someone reads it, works out which documents are affected, drafts language, routes it, and chases approvals through successive committee cycles. Meanwhile the business keeps operating on the old version, which is the actual exposure.
Duplicate and conflicting language identified across the library, with a recommended single source for each requirement and a defensible case for retiring the rest.
Every surviving policy tied to the rules it implements and the controls that evidence it, readable in both directions.
When a regulation or your risk appetite moves, the affected policies, controls, and owners surface immediately instead of after someone reads the issuance.
A redline with the rationale, the citation, and the downstream control impact, assembled for risk committee review rather than drafted from scratch.
The change
- Effective and compliance dates
- Source citation
- Applicability to your institution
The redline
- Proposed language
- Sections affected
- Rationale for each edit
Impact
- Controls affected
- Models and processes touched
- Owners to be notified
The record
- Reviewers and comments
- Committee routing
- Approval and effective date
- Version history
A drafted change, with its citation and its basis
The platform identifies that a policy does not cover a requirement, drafts the language that would close it, cites the source it checked against, and scores its own confidence. A person submits. Nothing becomes policy because a model suggested it.
Every control mapped to the regulation behind it.
Rationalize controls related to regulatory changes and identify gaps.
NEXT STEPThe second domain is configuration, not a second project
The context layer that governs your agents is the same one that keeps models defensible, traces critical data elements, and maps policy to regulation. Adding the next domain means pointing it at different systems, not running another implementation.