Two Distinct Layers of AI Control
Enterprise AI oversight generally spans two distinct architectural layers, and conflating them is a common evaluation mistake. The first layer operates before and around deployment: policy authoring, model risk documentation, compliance scoring, and audit-ready reporting produced by governance or compliance teams. The second layer operates at runtime, while an AI agent is actively executing tasks, calling tools, or communicating with other agents.
Platforms associated with the documentation and risk-scoring category, including Credo AI and Holistic AI, are generally built around design-time and assessment-time workflows. They help organizations formalize AI risk policy, generate documentation for regulatory review, and score models or use cases against defined criteria. Trussed AI is positioned in the second layer, providing runtime governance and security controls that manage agent identity, enforce least-privilege permissions, and apply policy decisions to tool calls as they occur.
Neither layer replaces the other. Documentation and risk-scoring tools answer what the policy is and how risky a given model or use case appears on review. Runtime enforcement answers what a specific agent is allowed to do right now, and whether that decision can be proven after the fact. Organizations that implement only one layer typically discover the gap during an incident, an audit, or a production agent deployment that behaves outside its intended scope.
Where Documentation-Oriented Governance Platforms Fit
Governance and risk-documentation platforms, the category most closely associated with Credo AI and Holistic AI, generally center on artifacts such as model cards, risk registers, policy libraries, and assessment workflows completed by governance or compliance staff. Their primary output is evidence that a policy exists, that a risk assessment was performed, and that a model or use case was reviewed against defined criteria before or during onboarding.
This work is necessary. Regulatory frameworks, internal AI risk policy, and board-level reporting all require documented evidence of a governance process. But documentation-oriented tools are typically not built to intercept an agent's tool call in real time, verify an agent's identity against a live permission set, or block an unauthorized action as it happens. Their evidentiary standard is closer to confirming that a policy existed and was followed at review time than to demonstrating that a control actively prevented an unauthorized action during execution.
For governance leaders, the practical question is whether an auditor or regulator will accept documentation of intent as sufficient evidence of control, or whether they require proof that the control operated at the point an agent acted. As agent-based AI systems become more autonomous, the second standard becomes harder to satisfy with documentation alone.
Where Runtime Enforcement Fits
Trussed AI operates at the runtime layer, the point where an AI agent is actively making decisions, calling tools, or communicating with other agents. Verified capability areas include agent identity management, least-privilege permissioning, tool approval workflows, runtime policy enforcement, runtime monitoring, Model Context Protocol security, agent-to-agent security, and audit logging generated from live enforcement events rather than self-reported documentation.
This distinction matters architecturally. An agent identity recorded as descriptive metadata in a governance document is not the same as an agent identity enforced as a first-class construct that gates which tools an agent can call, which data it can access, and which other agents it can communicate with. Runtime enforcement requires instrumentation at the point of execution, whether through protocol-level controls such as Model Context Protocol integration or through policy checks inserted directly into an agent's tool-call path.
This is also where agent identity, least-privilege access, and tool-call governance diverge most clearly between the two categories. A documentation platform can record that an organization has a policy requiring least-privilege access. It cannot, by itself, verify that a specific agent's tool call was checked against that policy at the moment of execution. Runtime enforcement closes that gap by evaluating and logging the action as it happens, producing audit evidence that reflects what actually occurred rather than what was intended.