Methodology
How AI agents are tested and judged: our methodology
By George Bâtcă, Co-founder · Security testing and evaluation
Updated 3 November 2026
This is how AltaSec tests and judges AI agents, from the first scoping call to the verdict. Every conversation is judged by fixed rules first, then by AI judges from a different model family than your agent, and those judges are checked by native speakers. Every verdict comes with the conversation that proves it, and what we did not test is named, never counted as a pass.
1. Scope and authorization
Nothing is tested without your written authorization. Before any test runs:
- you give us access to your agent: an endpoint or a test chat (a test phone number once telephony testing launches). No access to your code or model;
- we agree what is tested and the limits (how many conversations, and how fast), so testing never disrupts your service;
- you tell us which journeys the agent handles (bookings, claims, refunds, address changes), in which languages and channels, what it must never share or do, and which failures you can't afford. That list is what we test against.
2. AI agent testing methodology: how the tests are designed
Each journey becomes a set of test conversations, which we call recipes. A recipe states the customer's goal, what the customer knows and the outcome we expect, not the exact words: real customers don't follow scripts. Recipes cover the three checks:
- AI security: prompt injection, jailbreaks, data-extraction attempts and pressure to break your rules. See AI red teaming.
- Customer simulations: the normal customer, the confused one, the impatient one, the one who corrects themselves halfway through.
- Language benchmarks: the same journeys in each language you serve, judged against what a native speaker expects.
We also agree what must never leak: your instructions, internal codes, other customers' data. We plant nothing in your agent, its prompts or its data. Every reply is checked against that protected content itself, so a leak is proven by the reply, not inferred.
3. How AI agents are tested: running the conversations
Simulated customers and attackers play the recipes against your chatbot. Every run stays within the request rate and volume you authorized. If your agent stops answering or errors pile up, the run stops, and the affected journeys are reported as NOT TESTED, with the reason. Your team can follow every run in the AltaSec console.
4. How voice agents are measured
A voice agent fails in one of three places: it mishears (speech-to-text), misunderstands (the AI model) or says it wrong (text-to-speech). We measure each part on recorded calls. If the transcript was wrong, the finding is a hearing problem, even when the answer that followed is wrong too; if the transcript was right and the answer wrong, it is the model. Every voice finding names the part to fix. See voice agent testing.
5. How every conversation is judged
In this order:
- Fixed rules check the facts: the amount, the date, the name, leaked personal data or protected content, the language of the reply. A fact is never decided by opinion, and an AI judge never overrules a rule.
- AI judges score what rules can't decide: was the answer right, the tone right, the request handled. They come from a different model family than your agent, so a model is never grading its own kind.
- Native speakers check the judges. In each language, native speakers decide what is right on a set of conversations, and we compare the AI judges with them. We rely on an AI judge in a language only once it agrees with the native speakers. Until then, their judgement stands. Calibration is in progress, language by language. More on native speaker evaluation.
6. How results become a verdict: the Passport
Every journey, language and channel ends in exactly one verdict:
| Verdict | What it means | What backs it |
|---|---|---|
| GO | Ready for this journey, language and channel | Every check met, with the evidence |
| REVIEW | It works, with a problem to fix first | The finding, its conversation and a suggested fix |
| NO-GO | A failure you can't afford | The finding and its conversation. Some failures are never averaged away: one case of another customer's data is a NO-GO |
| NOT TESTED | It could not be tested | The reason, for example the agent stopped answering. Never counted as a pass |
With the verdicts you receive every test conversation in full, a suggested fix per finding, and the list of what was not tested and why. Results hold for the version we tested, at the time we tested it; no test can prove an AI is right 100% of the time. The Passport is our verdict with evidence, not a certificate, seal or badge. Next: every finding will be tagged with a failure mode and pointed at the OWASP Top 10 for LLM Applications, NIST AI RMF and the EU AI Act as input for your own assessment, never as a compliance verdict.
7. Data handling
Engagement data is processed in the EU only, with every sub-processor named in our data processing agreement. You keep the Passport and its evidence. Our copy is pseudonymised and deleted when the engagement closes. Every example on this site is synthetic.
What is in development
- AI security and customer simulations by voice.
- Step-by-step scoring of customer simulations.
- Real-world call conditions: background noise, phone lines, accents.
- A re-test comparison after every release, so you see what changed since the last Passport.
- Attacks hidden in what your agent reads (documents, web pages, knowledge bases), and scanning the data fed to your AI for personal data and secrets.
- Security attacks in Romanian and European Portuguese in chat, then Dutch and more European languages. Today security attacks run in English, and voice is measured on recorded calls in Romanian and European Portuguese.
- Calibrating the AI judges against native speakers, language by language.
- Graded results for the simulated customers (personas).
- Testing your own voice agent by phone.
- Findings tagged with a failure mode and pointed at OWASP, NIST AI RMF and the EU AI Act.
Frequently asked questions
Why use AI judges at all instead of people?
Because a test run produces more conversations than people can read with the same care every time. People still set the standard: native speakers decide what is right in each language, and an AI judge is only relied on once it agrees with them.
Why must the AI judge come from a different model family?
A model judging its own family can share its blind spots and miss the same mistake it would make. A judge from another family is a second opinion, not an echo.
Can we see the conversations behind a verdict?
Yes. Your team gets its own console login and sees every test conversation in full, including the ones that passed.
Does a GO mean the agent will never fail?
No. A GO means every check we ran was met for that journey, language and channel. A change to the model, the prompts or the knowledge base can break something that worked, so test again after each one. Our AI chatbot go-live checklist covers what to check before launch.