TEVV stands for test, evaluation, verification and validation, the NIST AI RMF's term for the checks that run across an AI system's life. For an AI agent, each word does different work: tests run cases, evaluation scores them, verification proves the controls work as built, and validation confirms the agent is fit for its real job.
What does the framework ask for under TEVV?
The NIST AI Risk Management Framework 1.0 treats TEVV as a set of tasks performed throughout the lifecycle, not a single gate before launch. It expects TEVV during design, development, deployment and operation, and expects some of it to be carried out by people independent of those who built the system. Measure is the function where most TEVV lives, but its results feed Map, which may be revised, and Manage, which decides what to do.
The framework does not define test methods, thresholds or report formats. It is voluntary. For the wider context, see how the NIST AI RMF applies to AI agents, and for the general discipline of judging AI output, our glossary entry on AI evaluation.
Who does TEVV apply to?
Organisations that adopt the framework. In regulated firms, the work usually splits. The team that operates the agent tests and evaluates. A separate function, often model validation, verifies and validates. Where an agent comes from a vendor, the vendor's own testing is an input, not a substitute: only the deploying firm can validate the agent on its own cases.
What does each part of TEVV mean for an agent?
The four words are often blurred. For agents, keeping them apart is useful because each produces different evidence.
Test means running the agent on cases and recording what happens. For an agent, a test case includes the input, the sources available, and the tools it may call. The record includes the answer and every action attempted.
Evaluation means judging those results against criteria. Was the answer grounded in the sources? Did the agent refuse what it should? Did it escalate the cases a person should decide? Did it call the right tool with the right values? Each criterion gets a floor.
Verification asks whether the agent was built as specified. For agents this is where firms most often have a gap. Verification checks that the controls work: that an attempt to call a tool outside the agent's scope is blocked, that an amount above the limit is held for a person, that every verdict is logged, and that an external document cannot authorise a payment. You verify these by trying to break them.
Validation asks whether the agent is fit for its intended use, in its real setting. It uses the firm's own historical cases, reviewed by someone independent of the builders, and ends in a decision: the agent may perform this capability, at this level of authority, for now.
How do TEVV tasks change across the agent's life?
At design, verify that the brief and bounds match what Map recorded. Before deployment, test, evaluate and validate each capability. In operation, keep testing: replay fixed cases on a schedule and after every change. Our piece on monitoring and drift under the NIST AI RMF covers the post-deployment side.
When you change the agent, compare old and new versions on the same cases before switching. A live comparison, where some traffic goes to the new version in drafting mode, is a form of A/B testing, but keep the new version unable to act until it has passed the same floors as the old one.
Take an illustrative case. A wealth manager's agent prepares client meeting summaries and drafts follow-up emails. Testing and evaluation show accurate summaries. Verification finds the agent could send an email directly if the drafting step timed out, a path nobody intended. Validation is paused, the path is closed, and verification is repeated. Without the verification step, testing would have passed an agent with a gap in its controls.
How do you meet TEVV for agents?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Test across the lifecycle | Case-based test runs at design, pre-deployment and on a schedule in operation | Test logs with inputs, outputs and attempted actions |
| Evaluate against criteria | Floors per metric: grounding, refusal, escalation, scope, action accuracy, harm | Scored results per case and per metric |
| Verify controls | Adversarial checks that limits, holds and logging work as specified | Verification report listing each control tried |
| Validate fitness for use | Independent review on the firm's own cases, ending in an approval decision | Validation report and signed approval |
| Independence | Validation done by people outside the build team | Reviewer names and reporting line |
| Re-test after change | Model, brief, source or tool change triggers re-run | Change log tied to new results |
| Compare versions | New version runs in drafting mode alongside the old before switching | Comparison report |
What will a supervisor, auditor or customer ask?
- What is the difference between your testing and your validation, and who does each?
- Show us a verification test where you tried to make the agent exceed its limits.
- Which cases were used for validation, and why are they representative?
- What happens to the agent if a scheduled re-test fails?
- How do you validate a vendor's agent on your own data?
What does TEVV under the framework not cover?
It does not set pass marks, approve agents or give you a certificate. It does not require external validation, though binding rules may. In the EU, the AI Act sets testing and accuracy duties for high-risk systems; our comparison of the EU AI Act and NIST AI RMF for agents shows where TEVV evidence can be reused. For banking model risk rules and other binding requirements, see our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Is red-teaming part of TEVV?
Yes, as a form of verification and testing. It probes the edges: attempts to make the agent exceed its bounds or follow injected instructions. It complements, rather than replaces, validation on representative cases.
Can the same person test and validate an agent?
They can test, but validation should be independent of the people who built and tuned the agent. Independence is what lets validation find the assumptions the builders no longer see.
How long does TEVV evidence stay valid?
Until something changes or a set period passes. Agents change often, through model updates, new sources and new tools, so evidence should carry an expiry date and be renewed by re-testing.