Scan prompts and behavior
ZeroLeaks tests whether your system instructions, model behavior, and response patterns hold up against adversarial inputs.
LLM Security Scanner
Automated LLM assurance
An LLM security scanner built for production teams
ZeroLeaks turns AI red teaming into a repeatable scan with vulnerability scoring, findings, transcripts, and remediation guidance.
Automated prompt injection and extraction scans
Security scoring and finding severity
Reports for engineering and compliance workflows
Cover injection and extraction
The scanner covers prompt injection, system prompt extraction, multi-turn escalation, tool abuse, and agent-specific risks.
Track security posture
Scores and reports help teams compare scans over time, validate fixes, and document AI security work for stakeholders.
Pick the scan that matches your stage
Different points in a project need different fidelity. A prompt being drafted does not need a live agent harness, and a deployed agent is not meaningfully tested by scanning its prompt in isolation. ZeroLeaks exposes several scan types through one API.
Prompt scans
Test a system prompt before an application exists around it. Hosted model simulation, fastest to run, ideal while instructions are still being drafted.
Runtime scans
Highest fidelity. Probes execute through your real application code with your models, tools, memory, and middleware in the loop, and credentials stay in your infrastructure.
Endpoint scans
Point the scanner at a deployed HTTP agent. Exercises the production contract including authentication, response parsing, and declared tools.
Skill scans
Static and behavioral analysis of agent skills and manifests from a repository, URL, or archive, for checking capability before it is installed.
Framework adapters
First-class adapters for the AI SDK and OpenAI, covering tool schemas, executions, and multi-turn state without writing a custom harness.
CI integration
The SDK and REST API are built for pipelines, so a scan can gate a pull request and a regression fails the build rather than reaching production.
What a scan produces
The output is a report rather than a log. Each run yields an overall security score, a list of findings with severity, the full attack tree showing which paths were explored and which were pruned, conversation transcripts, and for runtime scans the actual tool calls with their arguments and results.
Severity reflects what was reachable rather than a generic category rating. A tool-abuse finding on a read-only lookup and one on a credential-bearing write are not the same risk even when the technique is identical, and the report distinguishes them.
Reports are available through the dashboard, the API, and as PDFs, and can be shared through a link for stakeholders who need the result without access to the platform. That tends to matter for security review and procurement, where the audience for the evidence is not the team that ran the scan.
Scanning as a regression test
The highest-value way to use a scanner is not the first run. It is the hundredth. The first run tells you where you stand. Every subsequent run tells you whether the change you just made broke something that previously held.
This matters more for AI systems than for conventional code because the failure is non-obvious. Tightening a system prompt to fix a support complaint can weaken an instruction that was holding an injection boundary. Adding a tool to an agent expands the reachable surface for every existing probe. Neither change looks like a security change in review.
Running scans in CI puts that check where the change is made. Scores are comparable across runs, so a drop is attributable to a specific pull request, and a fix can be confirmed to hold rather than assumed to.
Scanning and runtime defense are different jobs
Scanning is a development-time activity. It finds vulnerabilities so they can be fixed, and its value is measured in issues resolved before release. Runtime defense is a production activity, blocking or sanitizing traffic in the moment, and its value is measured in attacks stopped.
Teams sometimes treat these as competing purchases. They address different failure modes. A scanner will not stop an attack in progress, and a runtime filter will not tell you that your retrieval layer treats untrusted documents as instructions.
The Shield SDK covers the runtime side with local prompt hardening, injection detection, and output sanitization, including n-gram matching that catches system prompt fragments in output. It is heuristic and it says so plainly: it catches known patterns quickly and does not claim to catch novel semantic attacks or complex multi-turn grooming. Those are what scanning is for.
FAQ
What does an LLM security scanner test?
It tests how an AI system responds to adversarial prompts, whether hidden instructions leak, and whether tools or agents can be abused. Unlike a code scanner it evaluates runtime behavior, because that is where the vulnerability lives.
Can ZeroLeaks be used before deployment?
Yes. Prompt scans work against a system prompt before any application exists, and runtime scans work in CI so changes are tested before they ship.
How does this differ from an open-source scanner?
Open-source tools like garak, PyRIT, and Promptfoo are capable and worth knowing. The practical differences are the adaptive attack tree rather than a fixed probe battery, the relay protocol for testing production agents without exposing credentials, and reporting built for sharing with people outside the engineering team.
Do you have an open-source option?
Yes. The zeroleaks package is an open-source local scan engine and CLI that runs against your own model-provider credentials, and the Shield SDK for runtime hardening is separate from the hosted platform.
How is the security score calculated?
From the findings a scan produces, weighted by severity and by leak depth for extraction results. The absolute number matters less than its movement across runs, which is what makes it usable as a regression signal.
Can I run scans from my own pipeline?
Yes. The SDK is server-side and calls the versioned REST API with a bearer key, so scans can be triggered from CI, a cron job, or an internal service, and results can be fetched programmatically.
Does the scanner need access to our infrastructure?
Not for prompt scans. For runtime scans the relay protocol inverts the connection, so your SDK process claims probes and executes them locally. Credentials stay with you and the target needs no public URL.
Related AI security testing
Prompt Injection Testing for AI Systems
Test AI applications for prompt injection, instruction hijacking, tool abuse, and multi-turn attacks before they reach production.
AI Red Teaming for LLM Apps and AgentsAutomated AI red teaming for LLM applications, agents, system prompts, retrieval flows, and tool-calling workflows.
System Prompt Extraction TestingFind whether your AI assistant leaks system prompts, hidden policies, tool schemas, retrieval instructions, or internal operating rules.
AI Agent Security TestingTest AI agents for prompt injection, unsafe tool calls, over-permissioned actions, secret exposure, and workflow boundary failures.
