Trust Center

Before it makes sense to use our services, there's a necessary question to answer first: what do we actually mean by cybersecurity for LLMs? Put simply — it's the study of the failure modes LLMs can have in production, the conditions that lead to them, and their possible mitigations.

Large language models have a high probability of not behaving as expected, in many different ways — which makes them insecure when used without the right safeguards. On top of that, they need to run on software like PyTorch, ONNX or CUDA, which can carry its own vulnerabilities. And the way LLMs get deployed and how their outputs get used adds a third layer of risk: when a model behaves unexpectedly, that behavior itself becomes a security risk.

LLM security is a far broader and less-explored field than what's covered today, separately, by traditional information security knowledge or by LLM/NLP knowledge. It's the union of both — everything we already know about information security, plus everything we already know about natural language processing.

There are dozens of open-source tools for testing LLM security — the same ones we use: PyRIT, garak, promptfoo, among others. Any team can download and run them. Getting the tools isn't the problem — each one speaks a different language, returns results in a different format, and none of them tells you what a garak finding means when cross-referenced with a PyRIT one, or whether that finding is enough to show an auditor your agent meets NIST AI RMF.

Running a tool against your model gets you a list of warnings in a terminal. It doesn't get you a team that knows which ones actually matter, that reruns the same attack plan after every model or prompt change, that turns each finding into an active guardrail in production, or that maps it automatically to the regulatory frameworks a customer or regulator is eventually going to ask for.

That's why Vapi isn't a toolbox: it's the team that operates the tools for you, cross-references findings across engines, and turns them into audit-ready evidence. Open-source tools are the starting point of any serious AI security exercise — our work starts where a terminal's output ends.

That work doesn't freeze the day we hand it over, either: attack techniques keep changing — new jailbreaks, new adversarial fine-tuning methods, new model architectures — and our test suite gets updated at the same pace. A toolkit you download once stays fixed at whatever version shipped that day; our engines get reviewed, expanded and tuned continuously, so what we test today still holds up against what an attacker tries next month.

An automated detector can flag it as "vulnerable" when a model generates, say, offensive content from an ASCII-art prompt or a message hidden through steganography — real probes that engines like garak run. But that alarm only makes sense if there's a policy in place first, defining what the model isn't supposed to do. Without that policy, there's no failure mode to evaluate: the model didn't "fail" anything, because nothing was ever defined as success.

Generating adversarial content without a policy isn't, on its own, a security problem — it's just bad form. Confusing the two is exactly what produces false positives: a finding that looks severe in an automated report but, checked against the agent's actual usage policy, carries no real risk. Our team reviews every finding against the customer's policy before reporting it as a vulnerability — we don't just forward a detector's raw output.

And that policy isn't static either: it changes with every model version, every new prompt, every use case that gets added. That's why we treat LLM security as continuous red-teaming against that policy, not a one-off audit — every time something changes, we ask again what actually counts as a failure mode before testing again.