Chat, RAG, APIs, tools, MCP servers, autonomous agents, voice — if it is part of your AI system, we attack it. Every surface, one engagement, and every finding proved with evidence you can re-run yourself. See what we actually found — five anonymized engagements
Subscription-aware access is loaded automatically.
AI stopped being one chatbot on a website. It is the assistant your customers type to, the knowledge base behind it, the APIs underneath, the tools and MCP servers it calls, the agent working a queue at 3am with real credentials — and increasingly the voice on the end of a phone line. Each fails differently, so each is tested differently. Under one report.
alg:none, weak-key signing, missing expiry checks, replayA scanner runs a list. This does reconnaissance, forms a view of your business logic, and spends the rest of the run acting on what it learned — which is why the second half of an engagement finds things the first half could not have known to look for.
Not categories we could test. Things we have actually got out of running AI products.
A voice agent gave up its operating instructions across four spoken turns
Every individual turn was a polite refusal. Judged turn by turn it was a clean pass; judged across the whole conversation it reconstructed the agent's own rules.
evidence: call recording + transcriptA widget's session endpoint minted billable sessions, unauthenticated
No prompt cleverness needed. The HTTP layer in front of an agent is often the softest part of it, and every call provisioned real capacity on the operator's bill.
evidence: request/response pair, replayableFive tool descriptions on a live MCP server carried instructions aimed at the calling agent
Tool descriptions are handed to a consuming model as trusted context, so any agent that merely lists that server reads them. The same engagement found the server's object authorisation to be sound - and the report says so, because a clean result you can trust is worth paying for too.
evidence: request/response pair, replayableSix API hosts the browser already ships, none of them in the docs
Read straight out of the production JavaScript bundle. You cannot test a surface you never found, so discovery caps every other number on this page.
evidence: source reference, per hostAnd the part most vendors leave out: against a hardened agent, none of our ten extraction techniques recovered a discrete secret. Instruction reconstruction is what actually works, so that is what we claim — and the report states which attacks failed, not only which landed.
A scanner looks for flaws in code. The failures that matter in an AI system are behavioural, and they surface only when something argues with your model the way an adversary would.
Vulnerabilities live in prompts, system instructions, and multi-turn context - invisible to any scanner that doesn't talk to your model like an attacker.
Not a buffer overflow - convincing your AI to expose another user's data, skip an approval, or leak a system prompt. That needs domain-aware attacks.
A guardrail that held last quarter can break after a fine-tune or prompt change. Point-in-time tests go stale; continuous red teaming catches it.
The EU AI Act, NIST AI RMF and sector guidance increasingly require documented adversarial testing of high-risk AI.
Security stops being the thing that delays the launch and becomes the thing you sell with. Continuous, evidence-grade proof that your AI holds up — ready before the questionnaire arrives.
Your staff are already using internal AI that touches sensitive data. You need to know it cannot be talked into leaking across users or over-reaching its tools — and to show an auditor you tested for exactly that.
The full attack catalogue, how defensible the output is under audit, and how an autonomous attack engine is kept from being misused. Open whichever one your review board cares about.
Jailbreaking the model is table stakes. Real AI breaches happen where the model meets your APIs, your tools and your business workflow — so every family below is exercised against whichever of your six surfaces actually exposes it, and proved with evidence rather than theory.
All four layers are attacked over text and over live audio in the same engagement, so a weakness that only appears when the channel is speech still lands in the same report. See how voice testing works ›
25 attack families plus an always-on credential-reuse pivot, each mapped to OWASP and MITRE ATLAS. Every one is exercised against whichever surfaces your system actually exposes.
Direct instruction-override against the system prompt.
OWASP LLM01 · AML.T0051Injected instructions via retrieved content, docs, and images.
OWASP LLM01 · AML.T0051Extracting secrets, system prompts, and PII from the model.
OWASP LLM02 · AML.T0057Role escalation, approval spoofing, and authority abuse.
OWASP LLM03 · ASI03Unauthorized tool calls and parameter smuggling.
OWASP LLM03 · ASI02Retrieval steering, context poisoning, and citation forgery.
OWASP LLM01 / LLM09 · ASI06Embedding-space geometry attacks - cross-tenant inference, semantic-cache poisoning, retrieval jamming, membership inference.
OWASP LLM09 · ASI06Encoding, unicode, and multi-step payload hiding to evade filters.
OWASP LLM01 · EvasionImage- and document-borne instruction attacks.
OWASP LLM01 · MultimodalPlan and tool-chain manipulation against agentic systems.
OWASP LLM01 / LLM03 · ASI01Long-horizon state corruption and memory steering.
OWASP LLM01 / LLM05 · ASI06Context leakage across users and conversations.
OWASP LLM02 · ASI06Poisoned retrieved content and document supply chain.
OWASP LLM01 / LLM04 · ASI04Structured-output and parser-boundary attacks.
OWASP LLM10 · ASI02Object- and function-level authorization probes against your API.
OWASP API01 / API05alg:none, weak-key signing, missing expiry checks, and token replay against your auth layer.
OWASP API02 · Broken authDouble-spend and check-then-use races on tool/workflow actions, with before/after state proof.
OWASP API · Business logicRedirects the agent's terminal objective toward the attacker's goal while it appears on-task.
OWASP LLM01 · ASI01 · AML.T0081Self-asserted identity, role and permission claims accepted without verification.
OWASP LLM01 · ASI03 / ASI07 · AML.T0091Chains the agent's own tools to hop across connected systems from an assumed identity.
OWASP LLM03 · ASI03 · AML.T0053Model output reaching a browser, shell, or query as trusted content - the reply is the payload rather than the leak.
OWASP LLM10 · ASI05Gets the system to explain the pricing, limit, and eligibility rules behind its answers, then breaks them.
OWASP API · Business logicPolicies, prices, or entitlements the system invents and a customer could act on. Nothing is breached - the answer is simply false.
OWASP LLM07 · ASI09Unsupported, false or incomplete claims that a human, workflow or tool acts on - false state, critical omission, forged evidence.
OWASP LLM07 · ASI09Assesses how far the deployed model can be partially replicated or mined by black-box querying.
OWASP LLM06 · LLM02Harvests a leaked token/key/cookie and re-authenticates with it (read-only) to prove the access it unlocks - session hijack, not just disclosure. Always on.
OWASP API02 · Credential accessIt doesn't end at the report. Ship a fix, re-run the engagement, and every finding returns a fixed / still-failing / regressed verdict - so you can prove the gap is actually closed.
We don't just tell you what broke - we tell you which control failed and what it could mean for compliance. Each confirmed finding is mapped to the relevant threat taxonomy and, where applicable, to the specific articles of the regulations governing your AI.
Handing a team an autonomous attack engine raises an obvious question: what stops it being aimed at the wrong target, or breaking the system it tests? These controls are built in - not optional add-ons.
Default-deny by domain: an account can only run against systems it has verified it controls. New targets require explicit authorization - so the engine can never be pointed at someone else's AI.
Never issues destructive requests (no PUT / PATCH / DELETE) and skips destructive tool and MCP actions in production. Declarative rules-of-engagement are enforced at a single chokepoint across every executor.
Refuses to touch internal, loopback, reserved, or cloud-metadata addresses - always on, regardless of configuration. Every run stays confined to the endpoint you provide.
Secrets and PII are redacted before anything is written to storage; raw sensitive values are never persisted. Attacker payloads and canaries stay intact, so findings remain fully reproducible.
Hosted on AWS in ap-south-1 (Mumbai); AES-256 at rest and TLS 1.2+ in transit. Security-relevant events are written to a tamper-protected audit log with 365-day retention.
Every engagement is cooperatively abortable mid-run and re-runnable after a fix, returning a fixed / still-failing / regressed verdict per finding - so you can prove the gap is actually closed.
Before you see it, every finding is re-checked against what we actually captured. A claim that outruns its proof is downgraded automatically and the report shows the downgrade - a status code alone can never be a Critical. Each finding also states the observation that would make it true, so you can check our work rather than take it on trust.
If an attack class never actually reached your system - a refused tool, an unreachable surface, a budget cut short - the report says not tested rather than showing you a clean row. Silence and safety look identical on a page, and only one of them is true.
One request-rate ceiling across the entire engagement - discovery, enumeration and follow-ups all draw on the same allowance, spaced evenly rather than in bursts. Set it to match what your production capacity tolerates, or leave it uncapped for a sandbox.
Elsewhere, “we support voice” usually means a transcript pasted into a text API. We place the call. We speak, listen, interrupt, and verify the agent actually heard us — same attack families, same evidence standard, same report as every other surface.
Give us the number your customers call. We dial it, speak to your agent, listen to what it says back, and press the attack across the turns of a live call.
The "talk to our AI" button on your product or landing page is a live, usually unauthenticated entry point. We join the same realtime session your visitors do.
Voice is a surface in our engine, not a separate product - which is what lets the same run cover text and audio together.
Scored across the whole conversation, because an agent that refuses every direct request still gives its rules away a piece at a time - which per-reply scoring never sees.
OWASP LLM07 · DisclosureText tricks like base64 do not survive being spoken. Paced delivery, spelling-out and phonetic framing do - so those are what we use.
OWASP LLM01 · EvasionTalking over the agent mid-sentence to cut off its safety preamble and land the request while it is recovering.
Voice-specific · Turn controlUnauthenticated session minting, JWT scope and expiry tampering, and weak-signing-key recovery on the token that gates the call.
OWASP API02 · Broken authClaiming to be a supervisor, engineer or verified customer on a channel where there is often no authentication at all.
OWASP LLM06 · Excessive agencyWe test where the agent hands off to a person - and stop there. A tripwire ends the call rather than occupying one of your staff.
Rules of engagementEvery spoken attack is round-tripped through our own speech recognition before it counts: if the target could not have heard it, we report it as undelivered, never as a pass. The call recording is attached to the finding — our audio on one channel, your agent on the other.
Reachable over SIP/PSTN for real phone calls, and over WebRTC or WebSocket audio for anything embedded — Twilio, Telnyx, LiveKit, OpenAI Realtime, ElevenLabs, Deepgram, or your own protocol.
AI red teaming is adversarial testing specifically designed for LLM-based systems. A regular penetration test looks for code-level vulnerabilities - SQLi, XSS, misconfigurations. AI red teaming looks for behavioral vulnerabilities: can an attacker override your system prompt? Can they access another user's data through the chat interface? Can they manipulate the model into bypassing an approval workflow?
These risks don't appear in CVE databases and can't be detected by any scanner. They require an engine that generates context-aware, business-model-aware attack prompts and evaluates the model's responses the way a skilled human adversary would.
Most "AI red teaming" tools test foundation models in isolation - jailbreaking GPT or testing Claude for harmful content. That's useful, but it's not the risk your business faces.
HiltLock tests your deployed AI application: your system prompt, your RAG pipeline, your tool integrations, your user identity model, your data access patterns. The attack surface is the full stack, not just the model layer. We generate targeted attacks that incorporate your org context, data domains, and known capabilities - the same information an insider threat or determined external attacker would use.
It's fully automated and runs through the dashboard. You configure your target endpoint, describe your organisation and data domains, and select the attack families to test. The engine then runs a four-phase process:
A structured report containing:
Yes - restraint is built in, not bolted on. The engine runs only against targets you have verified you control: access is default-deny by domain, and a new target must be explicitly authorized before any run can start, so it can never be aimed at someone else's AI.
In production it is non-destructive by design - it never issues PUT / PATCH / DELETE requests or destructive tool/MCP actions, and declarative rules-of-engagement are enforced uniformly across every executor. An always-on SSRF guard refuses internal, loopback, and cloud-metadata addresses, and each run stays confined to the endpoint you provide. Secrets and PII are redacted before anything is stored. Many customers still prefer to start against a staging environment - that works too.
To make setup fast even for non-technical users, the configuration screen can auto-fill itself from a browser capture: paste a cURL command, or upload a .har file, from a single real chat with your AI, and the system URL, connection details, request format, and login token are detected and filled in for you. The file is parsed entirely in your browser and never uploaded.
Yes, and it is one of the few areas where automated adversarial testing barely exists today. There are two routes in, and we support both:
Two other things help: a call budget (each attack chain is a real call, with real speech-processing cost on your side - we cap calls, turns and duration, and the defaults are deliberately conservative), and the phrase or number your agent uses to transfer to a human, so our tripwire ends the call rather than occupying one of your staff.
To be explicit about what we do not do: we never clone a real person's voice or impersonate a named individual. Every call is made in our own clearly synthetic voice. The attack is on your agent's reasoning and its authorization boundaries, not on your callers.
On the recordings themselves: they are encrypted, never public, reachable only through an authenticated request scoped to your run, and they expire automatically — 90 days where the call produced a finding, 7 days otherwise. The transcript and the finding are retained, so the evidence trail outlives the audio.