Product
A narrow product with a hard boundary
TrustRail is not an agent builder, a model gateway, or a governance inventory. It owns five things in the release path and hands everything else back to your team.
The boundary
- Running repeatable journeys against an agent
- Connecting conversation, agent, handoff, model, tool and system-state events into one chain
- Checking controls, both deterministic rules and statistical requirements
- Recording exactly which configuration and software was tested
- Packaging the result as reviewable, signed evidence
- The agent and its business logic
- Production and test systems
- Authentication and authorization policies
- Your internal control definitions
- Legal and regulatory interpretation
- The release decision
Components
Six parts
Runs scripted or model-assisted interactions against the agent under test, repeatedly, and measures cost and runtime.
Connects to agent frameworks through OpenTelemetry, MCP, APIs and trace exports. The adapter contract stays framework agnostic on purpose.
Turns framework-specific events into stable agent, tool, handoff and state entities. Everything else is built on this.
Runs deterministic rules and state assertions, measures stability across repeated runs, and uses a judge only where a rule cannot decide.
Hashes and records the agent configuration, prompts, tools, models, policies and scenarios, so the tested thing is provably the released thing.
Produces signed evidence and plugs into CI/CD or change approval. It stays advisory until there are real gate statistics behind it.
Coverage
Frameworks and domains
Frameworks
The aim is to support the major agent frameworks, and adding one is a single adapter rather than a rebuild. Two deep adapters exist today, for Google ADK and LangGraph.
- Google ADK
- LangGraph
- Managed platforms
- Custom REST and SSE agents
We built those two first because their execution models are so different. ADK runs a root orchestrator that hands off to a specialist sub-agent with real handoff lineage, and LangGraph runs a single graph. If normalisation holds across those, it holds.
The rest get built when a customer needs one. Two deep adapters beat four shallow ones, and it would be dishonest to sell an adapter that can only read conversation text alongside one that can prove an action.
Domains
The engine does not care about the domain. What changes is a pack: the journeys, the entities, the expected system state, and how those map to your controls.
The first pack covers financial servicing, because the actions are unambiguous and the mistakes are expensive. A second journey in that pack already runs on the same engine and the same controls with only the domain definition changed, which is the part worth testing rather than asserting. See the worked example.
Honesty mechanism
Declared assurance levels
Every integration has to declare what it can actually prove. An integration that only sees a transcript is never allowed to imply it verified an outcome. The product enforces this, not the sales deck.
| Level | Name | Evidence available | Claim you may make |
|---|---|---|---|
| 1 | Conversation | Inputs, outputs, timings | How it behaved for the user, from the outside |
| 2 | Tool visibility | Tool names and partial execution events | Basic checks on the action path |
| 3 | Tool integrity | Tool arguments, results, retries, lineage | The agent picked the right tool with the right parameters |
| 4 | Outcome assurance | Level 3 plus system-state assertions | The action was correct end to end |
| 5 | Deployment assurance | Level 4 plus multi-agent lineage and artifact attestation | The tested artifact matches the release candidate |
Where a control returns INCONCLUSIVE
Authorization is the clearest case. If TrustRail starts a journey from a test harness you control, as a known synthetic user, it can say the journey behaved correctly for that identity. It cannot say how the agent received or passed on OAuth, session, or delegated authority details.
Proving that needs evidence from sources you approve, such as session or API gateways, tool
audit logs, OAuth introspection, or system audit events. Without it, the relevant controls
return INCONCLUSIVE and never PASS.
Scope
What this is not
Things we deliberately do not do
- A complete digital twin of your systems
- Every agent framework
- A general enterprise AI inventory or governance platform
- Vendor certification or public benchmarks
- Monitoring all of your production conversations
- Generating scenarios without a human
- Legal conclusions about any regulation
On regulation, precisely
TrustRail produces execution evidence you can feed into your own processes: logging, human oversight, quality management, change management, risk-based testing. Where something like the EU AI Act or DORA applies to you, that evidence is useful input.
It does not decide your legal classification, and it is not a compliance solution for any regulation on its own. A vendor who tells you otherwise is selling you a problem.
Simulation is optional, and it comes last
A synthetic environment is a service virtualization capability, not the headline. Use your existing sandbox first. Then observe or proxy real tool calls. Then check actual test-system state. Simulate only the things that are genuinely unavailable or too dangerous to touch.