IBM OpenPages is a governance, risk, and compliance platform that documents model inventory, validation status, and approval workflow for AI and machine learning models. Trussed is a runtime governance layer that enforces controls on AI agent identity, permissions, and tool calls as they happen in production. OpenPages answers whether a model was reviewed and approved. Trussed answers whether an agent's action right now is authorized. Most enterprises deploying autonomous or semi-autonomous agents need both: documentation for audit and reporting, and runtime enforcement for operational risk.
MRM Documentation vs Runtime Governance
IBM OpenPages vs Trussed: MRM Documentation vs Runtime Governance
IBM OpenPages documents model inventory, validation status, and approval workflow for AI and machine learning models. Trussed is a runtime governance layer that enforces controls on AI agent identity, permissions, and tool calls as they happen in production. OpenPages answers whether a model was reviewed and approved; Trussed answers whether an agent's action right now is authorized. Most enterprises deploying autonomous or semi-autonomous agents need both: documentation for audit and reporting, and runtime enforcement for operational risk.
Two Layers of AI Governance
Documentation and enforcement answer different questions. Neither replaces the other, and the space between them is where operational risk accumulates.
Documentation Layer
Model inventory, validation records, and risk ratings tracked in a system of record like IBM OpenPages.
Runtime Layer
Agent identity, permission scoping, and tool-call enforcement applied continuously during execution.
The Gap
Approved documentation does not restrict what an agent actually does after deployment.
Where Runtime Enforcement Sits Relative to Documentation
Each system owns a distinct record. Understanding which one applies to a given question prevents gaps from being assumed away.
- 1
System of record for risk rating
OpenPages remains the source of truth for documented model risk tier and validation status.
- 2
System of record for runtime decisions
A runtime governance layer owns allow or deny decisions on agent tool calls and permission requests as they happen.
- 3
Validation cadence vs live behavior
Periodic validation cycles do not account for agent behavior that changes between scheduled reviews, which is a separate operational risk to track.
- 4
Event capture for audit
If runtime tool-call events are required as audit evidence, a mechanism to log and retain them needs to exist independently of whether it feeds back into MRM documentation fields.
Questions to Answer Before Choosing One, Both, or Neither
These questions help clarify where responsibility sits before adding a new system or assuming an existing one already covers runtime behavior.
- Does our current MRM platform provide any mechanism to observe or restrict an agent's tool calls after approval, or does it only document approval status?
- Is our audit requirement documentation of risk rating, evidence of runtime access control, or both?
- How would a validation cycle account for an agent whose tool access changes between scheduled reviews?
- Who owns the decision boundary between a documentation requirement and an operational security control in our governance program?
- If we adopt runtime enforcement, how will its logs or decisions be reflected in existing MRM reporting, if at all?
What Each System Is Built to Do
IBM OpenPages is built to document model inventory, validation status, and approval workflow. It is the system of record for whether a model or agent was reviewed and formally approved. Trussed is built to enforce controls on agent identity, permissions, and tool calls as they occur in production, answering a narrower but operationally critical question: is this specific action, right now, authorized.
Side-by-Side: Documentation Layer vs Runtime Layer
OpenPages remains the source of truth for documented model risk tier and validation status; it does not observe or restrict what an approved agent does after deployment. A runtime governance layer instead owns allow or deny decisions on agent tool calls and permission requests as they happen, independent of the documentation cycle that produced the original approval.
Why the Regulatory Frameworks Leave This Gap
Periodic validation cycles do not account for agent behavior that changes between scheduled reviews, and this is a separate operational risk from the one documentation is designed to capture. Whether an audit requirement is satisfied by documentation of risk rating, evidence of runtime access control, or both is a question most governance programs have not explicitly assigned an owner to answer.
Practical Notes on Deployment Sequencing
- Confirm whether the immediate driver is an audit or regulatory deadline (favors documentation-first) or an operational incident risk (favors runtime-first).
- Treat mapping runtime enforcement events into an MRM platform's documentation fields as custom integration work, since this is not a native capability of documentation-only tools.
- Update SR 11-7-style validation procedures to explicitly state which risks are covered by documentation and which are intended to be covered by runtime controls, so the gap is documented rather than assumed away.
- Define agent identity and permission scope in writing during the validation process, even if enforcement of that scope happens in a separate runtime system.
- Avoid treating a documentation platform's approval status as equivalent to an operational guarantee that an agent cannot exceed its intended scope.
Documentation and Runtime Enforcement Are Not the Same Control
If your MRM platform tells you a model was approved but not what your agents are doing right now, that is a scope gap, not a system failure. Runtime governance closes the operational side without replacing your compliance documentation.
Explore AI Agent Security