A spreadsheet of clever prompts is not a red team.

Penetration testing probes your infrastructure: servers, APIs, networks and access control. AI red teaming probes model behaviour: whether the AI system can be talked into leaking data, ignoring its system prompt, calling a tool it should not, or producing harmful content. The target is the conversation rather than the stack, so the attacks are prompts and dialogues instead of exploits, and success is measured by what the model does, not by a shell you opened.

Prompt injection is an attack that overrides an AI system's own instructions with attacker-controlled text, either typed directly by the user or hidden in a document, web page or tool result the system reads. A successful injection can make the model ignore its system prompt, reveal it, or follow the attacker's commands instead of yours. It is the top risk in the OWASP LLM Top 10, and EvaliQA tests both direct and indirect, retrieved-data injection.

A multi-turn jailbreak is an attack spread across several turns rather than one prompt: establish a harmless frame, win a small concession, cite it as settled, then ask for the thing. Many AI systems that refuse a direct request concede it by the fourth turn, which single-shot tests never catch. EvaliQA runs these with scripted, simulated or adaptive attackers, including algorithms like Crescendo and TAP, under a turn budget you set, and scores the whole session on the outcome.

EvaliQA covers 33 vulnerabilities across safety, privacy, behaviour and access, including the risks the OWASP LLM Top 10 flags such as prompt injection, sensitive-information disclosure, system prompt leakage and excessive agency, alongside access-control flaws like BOLA and RBAC bypass. They are delivered through 30 attack techniques, from direct requests to encoding, roleplay, authority and multi-turn escalation. You pick the vulnerability and technique pairs, and every generated row is tagged with the pair it came from.

Regular evaluation asks whether the AI system does the right thing on the inputs you expect, and scores answer quality. Red teaming asks whether it can be made to do the wrong thing on inputs an attacker chooses. The dataset is adversarial and regenerated every run rather than fixed, and the score is the outcome of the attack, whether it breached or held, not how well written the answer was. Both run through the same wizard, so an attack success rate can gate a release like any other metric.

Yes. Manual red teaming does not scale and cannot be re-run every release. EvaliQA automates it: you describe the AI system and pick what to probe, and the platform generates the adversarial prompts, runs them against your endpoint over HTTP, drives multi-turn attacks with an attacker model, and scores every row on the outcome. Because the attempts are regenerated each run, an automated suite keeps finding fresh phrasings instead of replaying a stale list, and it can run in CI on every merge.

No. EvaliQA red teams black-box: if your AI system answers an HTTP request, a connector describes the endpoint, its headers and its response shape, and the attacks run against the system exactly as a user would reach it. You do not need the model weights, the training data or an SDK inside your app, so you can red team a third-party model or a system you only reach through an API.

It is included on every plan, not a separate SKU. Free carries a monthly allowance of attack cases and Team a larger one, and the adversarial attacker runs on the platform's own model, so there is no extra key to bring for it. An attack success rate behaves like any other metric, so you can put a threshold on it in CI and fail the build when a regression lets more attacks through.