Test every agent release against your own cases, your own defenses and your own bar before it ships.
An agent that passed a demo last month has since had a new prompt, a new tool and a new model. Praesidia scores each version against the cases you care about, checks synthetic attacks against organization-wide defenses, and turns the results into a release gate your pipeline asks before anything goes out.
- Pass rate ≥ 0.90
- ✓ Blocking · 0.93
- Mean score ≥ 0.80
- ✓ Blocking · 0.86
- Total cost ≤ $5.00
- ✓ Blocking · $3.12
- p95 latency ≤ 1,500 ms
- ! Advisory · 1,840 ms
Advisory fail
A missed blocking rule stops the release; a missed advisory rule is reported and recorded. Either way the verdict stays on the AI system's record.
Three things assurance gives you
Quality you can compare
Score each prompt version against the same dataset and see which cases regressed, not just whether an average moved.
Synthetic checks of your defenses
Schedule synthetic probes selected from opted-in targets and see the verdicts from organization-wide input guardrails and intent rules. Live endpoint behavior and agent-specific guardrails need separate validation.
A bar every release has to clear
Blocking rules hold back a release that misses them, and overriding a failed verdict takes a written reason that stays on the record.
Collect cases, score, attack, gate
- 1
Build a dataset from cases you write or from your agents' recent completed tasks.
- 2
Write the evaluation: what a good answer looks like, how it is scored, and the threshold it has to reach.
- 3
Run it against an agent's current prompt or a specific version, and compare the run with the last one case by case.
- 4
Opt in registered targets to select synthetic probes from their recorded context, and run checks of organization-wide defenses on demand or on a schedule.
- 5
Set release-gate rules on the AI system, and have your deployment pipeline ask for a verdict before each release.
What each part does, and where it stops
- Evaluations and runs
- An evaluation scores an agent's answers against criteria you write, either as pass or fail or on a scale, with a passing threshold you set. Each run tests one active agent on its current prompt or on one specific prompt version and records the run's pass rate, mean score, response latency and cost. A completed run opens case by case, and runs can be compared side by side.
- Datasets and regressions
- A dataset is a named set of test cases — an input, the output you expect and your own tags — added by hand or imported from your agents' recent completed tasks, with personal data detected in an imported input redacted before the case is stored. Two runs over the same dataset are compared case by case: which cases regressed, which improved and which were unchanged, alongside each run's pass rate.
- Red-team campaigns and attack packs
- Red-team campaigns use synthetic attack probes selected from the recorded context of your own registered agents, connections and MCP servers, on demand or on a schedule. Targets must be explicitly opted in by your organization; other targets are refused. The attack library covers prompt injection and jailbreaks, scope escalation, out-of-scope tool use, bulk PII exfiltration, RAG poisoning, memory poisoning, malicious skills, cross-agent escalation, lateral movement, privilege escalation and policy bypass, with MCP-specific probe classes for poisoned tool descriptions, unauthorized tool chaining and credential leakage. Red-team campaigns are a plan feature; see pricing.
- What a red-team run tells you
- Probes check enabled organization-wide input guardrails and intent rules without calling the target's production endpoint. They do not test agent-specific guardrails or the live target's behavior. Configured model guardrails may call external evaluators with the synthetic content. Runs report observed verdicts and severity; high or critical severity findings can escalate to linked security incidents.
- Release gates
- Each AI system can carry release-gate rules on an evaluation run's pass rate, mean score, median latency, 95th-percentile latency or total cost, each marked blocking or advisory. Your deployment pipeline asks for a verdict with an organization API key and gets pass, fail when a blocking rule is missed, or advisory fail when only advisory rules are. A failing verdict can be overridden only with a written reason, and every verdict and override stays on the AI system's record.
- What it is not
- A passing evaluation, a clean red-team run or a green release gate is evidence about the cases, attacks and rules you ran — not a guarantee that an agent behaves safely in every situation, and not a substitute for your own review before a release.
Read the docs: evaluation datasets. Read more: red teaming AI agents · scoring agent quality and regressions. Then: runtime security · risk management.
Go deeper
- Building golden datasets for agent evals — choosing and maintaining the cases an agent is tested against.
- Guardrails vs evals vs monitoring — what each one catches, and when.
- The OWASP Agentic AI Top 10 guide — the agent-specific risks a red team should test for.
- The AI agent security guide — identity, authorization, guardrails, audit logging and incident response.
Put your first agent through a release gate
Start with one agent, one dataset and the bar you already hold it to.