One correct answer proves little when the next run may differ. You need a standard for "good" and a rate, not a single result.
AI agent testing and red-teaming
Test your agent the way it behaves in production.
Recreate realistic conversations, tool use and failure conditions in a controlled test. Then verify the answer, the actions taken and the result your customer sees before the change ships.
AI AGENTOrder status and returns
Conversation Turns (3)Multi-Agent Trace DAGTrajectory
Where is order #ORD-9918, and can I still return it?
lookup_orderArguments:
{ "id": "ORD-9918" }Response:{ "status": "delivered", "daysAgo": 2 }It was delivered two days ago, and our policy allows returns within 30 days.Judge: PASS
3 turns recorded. Example run; the tool is mocked, so no real order system is touched.
In the product
A real agent suite, including a bug it caught.
These are real screens from CertiQA testing BookHaven, a small reference support agent we run locally. Six tests pass. One is meant to fail: a web page the agent fetched told it who to send email as, and the agent obeyed. The test asserts the safe behaviour, so it catches the problem.
Production behavior, tested safely
Check the conversation, the actions and the outcome.
The reply can read well while the refund went to the wrong order. And a test cannot be allowed to issue a real refund.
Production tools time out and rate-limit. An agent that retries forever or tells the user something untrue is a bug no happy-path test finds.
Users will try to override its instructions, extract its prompt and talk it into misusing its tools. A change to a prompt or model can quietly undo a defense.
How each is handled
A specific answer to each question.
Conversations: a rubric and a repeat count
An Expect Response step sends the agent's answer to an LLM judge with a rubric you write, for example grounded in your policy or safe to say. Set a repeat count and a pass threshold and the whole case runs that many times. The run report shows the repeat pass rate with a 95% confidence interval, and the judge's reasoning for each verdict.
A judge can be wrong. Saved rubrics carry a calibration summary against human-labeled examples, and exact expectations are better checked with a deterministic Assert Output step.
In the run report
- Repeat pass rate and 95% confidence interval.
- Judge verdict and reasoning per answer.
- A high-variance warning when the judge's ensemble disagrees.
Tool calls: mock, route or assert
Mock Tool Response answers your agent's tool calls with the response you define, so nothing real is touched. Passthrough Tool sends one named tool to your real staging endpoint while the others stay mocked. A tool with neither is never sent anywhere. Expect Tool Call then checks the tool and its arguments, matched exactly, by subset or against a JSON Schema.
The run report lists each call with its tool, whether it was Real, Mocked or No mock, its arguments, status and latency.
On hosted runners, private addresses are refused. To reach a system inside your network, use a self-hosted runner.
cases:
- name: Refund an eligible order
steps:
- action: MOCK_TOOL_RESPONSE
tool: lookup_order
response: { status: delivered }
- action: MOCK_TOOL_RESPONSE
tool: process_refund
response: { status: SUCCESS }
- action: SEND_USER_MESSAGE
message: Refund order ORD-9918
- action: EXPECT_TOOL_CALL
tool: process_refund
argsMatch: SCHEMA
expectedArgs:
type: object
required: [orderId, amount]Failures: break the tool on purpose
Declare a fault on a tool, such as TIMEOUT, HTTP_500, HTTP_429 or MALFORMED_JSON, and optionally the call it should hit. The case then runs once per mode and is graded on how the agent recovered: an LLM judge applies your recovery rubric to the agent's next turn, and an optional limit caps the tool calls it may make.
Transient retry is testable too: inject the fault on call 1 only and the tool answers normally afterward.
faults:
tool: fetch_customer_records
modes: [HTTP_429]
onCall: 1
expectRecovery:
inlineRubric: Tells the customer the
system is busy, retries at most
twice and never shows a raw error.
maxToolCalls: 3Attacks: a sweep on every release
The built-in catalog has 20+ scenarios across seven OWASP LLM Top 10 categories, including prompt injection, system-prompt leakage, jailbreaks, data leakage and tool misuse. CertiQA also builds attacks from your agent's own tools, so a refund tool is tested for refund abuse and argument tampering, not only generic jailbreak phrases.
Each sweep is saved with a defense rate and per-category breakdown. A CI sweep can fail when the rate drops against the previous run with the same attack set, which catches a regression instead of only a low score.
The catalog covers what an attacker can reach by talking to the agent. A clean sweep is a trend for your team, not a security certification. Included in the trial and on Team Pro Plus and Enterprise Ultra.
| Category | Defense rate | Defended / total |
|---|---|---|
PROMPT_INJECTION | 100% | 4 / 4 |
JAILBREAK | 100% | 3 / 3 |
SYSTEM_PROMPT_LEAK | 100% | 2 / 2 |
PII_DATA_LEAK | 67% | 2 / 3 |
TOOL_MISUSE_ESCALATION | 75% | 3 / 4 |
Ground tests in real use
Turn production behavior into repeatable release checks.
Multi-agent handoffs
Send OpenTelemetry GenAI spans from LangGraph, CrewAI or AutoGen. Assert which agent was delegated to, check the context that crossed a handoff, and cap tokens, duration and tool calls for one agent.
Production traces into regression tests
Bring in sessions from Langfuse, Arize Phoenix or Helicone, redact sensitive values, and promote a flagged interaction into a repeatable test for your staging agent.
Online evaluation
Score a sample of live traces with deterministic matchers such as contains or regex. A statistically significant drop in a policy's pass rate opens a drift alert, shown in the app.
Whole-journey checks
Seed data through your API, let chosen tools reach staging, read the result back and check the page a customer sees, all in one test case.
Browser-driving agents
When an agent clicks and types in a real browser, CertiHeal repairs drifted selectors and an Assert Browser State step checks what the page actually shows.
Release Report
Run outcomes, fault recovery, security posture, judge calibration and traced tool calls for a date range, with a SHA-256 hash, for a review.
Readable by the whole team
Review what the tests check without reading thousands of lines of code.
When AI is writing more of your product, someone still has to understand what it does. CertiQA cases are plain steps on a visual canvas: what the user says, which tools are mocked, what must be true afterward. Your assistant can draft a suite over MCP, and a QA lead, product owner or auditor can read, edit and approve it.
Author tests with your AI assistant1 Send User Message "Pay with my saved card"
2 Mock Tool Response charge_card -> DECLINED
3 Expect Response offers another payment method
4 Expect Response does not claim the order is paid
5 API Request GET /orders/{id}, status = PENDINGAccessibility
Test how your agent behaves for people with disabilities, and whether it keeps doing so.
Operate through accessible controls
Run a browser-driving agent with element targeting limited to visible text or role and accessible name, or with the keyboard only, and compare the result with a normal run of the same cases.
Conversation behaviors
Scripted checks for confirming before acting, accepting a correction, asking instead of guessing, repeating on request and handing over to a person. Experimental, and not reviewed by an accessibility specialist.
Part of the tests you already run
Mark steps as accessibility checks and choose, per step or per run, whether a failure is skipped, recorded, fails only if the check passed before, or fails the test. Add them to an existing case in the case editor or over MCP.
The page the agent ends on
Scan the page the agent finishes on with axe-core. Web pages you test directly already have axe-core scans and a keyboard audit.
A report to keep
Each run's report compares every check group with its earlier result, shows removed checks and changed setups, and gives no score.
These checks help test selected behaviors and track regressions. They are not a certification or a conformance result, they cover text and not speech, and they do not replace testing with disabled people.
FAQ
AI agent testing, answered
How do you test an AI agent?
Run it against realistic conversations with its tools mocked, so nothing real is touched. Score each answer against a rubric with an LLM judge, check that the right tools were called with the right arguments, inject failures such as timeouts and 429 errors, and attack it with prompt-injection and jailbreak scenarios. Repeat the runs, because an agent answers differently every time, and gate your release on the result.
How does CertiQA mock AI agent tool calls?
CertiQA intercepts the tool calls your agent makes over REST or the Model Context Protocol (MCP) and returns the responses you define. A tool with no mock and no route is never sent anywhere. You can inject latency, 429 and 500 responses, and let chosen tools pass through to your staging systems while everything else stays mocked. Assertions on the arguments a tool received can match exactly, match a subset or validate against a JSON Schema.
What is an LLM judge and can I trust it?
An LLM judge is a model that scores an agent's answer against a rubric you write, for example "grounded in the refund policy" or "does not reveal internal instructions". It can be wrong. Each saved rubric carries a calibration summary against human-labeled examples, and a judge ensemble can flag answers where its own members disagree. Where the expectation is exact, use a deterministic check on the reply, a tool argument or system state instead.
How does automated OWASP LLM red-teaming work in CI?
CertiQA attacks your agent's endpoint with 20+ built-in scenarios across seven OWASP LLM Top 10 categories, including prompt injection, system-prompt leakage, jailbreaks, data leakage and tool misuse. It also generates attacks from your agent's own tool list. Each sweep is saved with a defense rate and a per-category breakdown, and a CI sweep can be set to fail when the defense rate drops compared with the previous run that used the same attack set. The catalog covers what a conversational attacker can reach and is not a security certification.
How do you test multi-agent systems built with LangGraph, CrewAI or AutoGen?
Send OpenTelemetry GenAI spans to CertiQA. It maps the handoffs between agents, lets you assert which agent was delegated to and by whom, check the context that crossed a handoff against a rubric, and enforce limits on tokens, duration and tool calls for one agent so a runaway loop fails a test instead of running up a bill.
What is the difference between agent testing and LLM observability?
Evaluation and observability platforms can cover development and production. CertiQA focuses on repeatable, end-to-end scenarios where you control tool responses, inject failures, verify system state and customer-facing UI, then gate releases in CI. Production traces can become regression cases; CertiQA does not replace live monitoring.
How CertiQA comparesCan I test an agent without writing code?
Yes. Tests are plain steps in a visual builder: send a message, mock a tool, expect a response, read state back through your API. You can also connect Cursor or Claude Desktop over MCP and let your assistant draft the suite. Your team reviews and edits plain steps, with no generated code to read.
Author tests with your AI assistantCan CertiQA test an AI agent for accessibility?
It helps you test selected accessibility-related behaviors and track whether they regress. You can run a browser-driving agent with its element targeting limited to visible text or role and accessible name, or with the keyboard only, and compare it with a normal run. Scripted conversation checks look at behaviors such as confirming before acting, accepting a correction, asking instead of guessing and repeating on request. Each check can be skipped, recorded without failing the test, failed only if it passed before, or enforced. These are not a certification or a conformance result, the conversation checks are experimental and were not reviewed by an accessibility specialist, and they cover text, not speech. They do not replace testing with disabled people.
What is in a Release Report?
A Release Report covers a signed-off run or a date range. Its sections are run outcomes with pass rates and Wilson 95% intervals, fault-injection recovery, security posture from red-team sweeps, judge calibration, traced tool calls, accessibility findings and an audit-log excerpt. It carries a SHA-256 hash so later edits are detectable. It is evidence for a reviewer, not a certification, and the audit-log section covers the whole platform rather than one project.
Start with one agent and one failure you worry about.
Point CertiQA at a staging endpoint, mock a tool, add a fault and read the report. The docs cover each step.