Your product now contains a component that reads untrusted content, holds credentials to internal tools, and can be persuaded. We test chat features, retrieval pipelines, and tool-using agents the way an adversarial user does, then show you precisely what they can make your system do.
Model-backed features ship in weeks; the security discipline around them is still being written. These are the attack classes we run against LLM features and agents, each mapped to the OWASP Top 10 for LLM Applications and updated as new techniques are published.
The primary input channel under sustained attack: instruction override, persona framing, encoding tricks, multi-turn manipulation, and refusal wear-down. We measure whether your system prompt and guardrails hold against a user actively working to break them, and how consistently they hold across sessions and model versions.
Hostile instructions arriving through content the model reads rather than text the user types: web pages an agent browses, documents in the retrieval index, email bodies, ticket fields, and tool outputs. We plant payloads in every ingestion channel in scope and observe which ones steer the model's behavior.
What leaves through model outputs: other tenants' records surfaced by retrieval, secrets present in context, and personal data the model was never meant to repeat. We also test covert channels, such as markdown images whose URLs carry conversation data to an attacker's server the moment the client renders a response.
Extraction of system prompts, tool schemas, and configuration through interrogation and side channels. Leaked prompts frequently expose business logic, internal endpoints, and occasionally embedded credentials, handing an attacker the exact instructions they need to craft a bypass. Where fine-tuning is in play, we probe for memorized training data as well.
Model output treated as trusted input becomes an injection vector. We test whether generated markdown and HTML reach the DOM unencoded, producing stored or reflected XSS, whether generated URLs are fetched server side and open SSRF paths, and whether generated code or queries execute with real privileges downstream.
The pipeline from ingestion to answer. We test whether an attacker can seed the corpus with content that hijacks responses, plant instructions that retrieval reliably surfaces, or abuse weak tenant isolation and metadata filtering in the vector store to read across customer boundaries.
For agents that call functions, browse, write files, or reach internal APIs, we test what injected instructions can do with those capabilities. That includes privilege and trust boundary violations: tools scoped wider than the calling user's permissions, and confused deputy chains through connected systems.
Unbounded consumption. Prompts engineered to maximize token usage, recursive agent loops, context stuffing, and request patterns that slip past rate limits to inflate inference spend or exhaust provider quotas until the feature degrades or your budget does.
The third-party surface of the stack: model weights and their provenance, fine-tuning datasets, plugins, connectors, and orchestration frameworks, plus the permissions each is granted. A compromised dependency at this layer sits upstream of everything the model produces.
Four stages, agreed in writing before testing begins. You know what we will attack, through which channels, and under what limits.
We inventory every model-backed feature in scope: the models behind them, the tools they can invoke, where untrusted content enters the context window, and the data behind each trust boundary. Together we agree on environments, test accounts, inference spend ceilings, and whether we work with sight of your system prompts and tool schemas.
Manual attack work against every input channel, with targeted automation for payload variation and coverage. We chain findings the way an attacker would: an injection planted in an indexed document becomes a tool call, which becomes data leaving through a rendered response. Every result is verified by hand.
The report arrives within five business days of testing completion, with exact payloads, full transcripts, affected components, and CVSS v3.1 severities weighted by demonstrated impact. Remediation guidance names the layer that must change rather than gesturing at better guardrails.
Once your fixes ship we rerun the reported attack chains with variant payloads, confirming each fix closes the class of attack rather than the single sample we reported. One retest is included in every engagement, and the report is updated to reflect the result.
Test cases are structured against published frameworks, so you can trace every finding back to a recognized attack class rather than a tester's improvisation.
The OWASP Top 10 for LLM Applications gives our model-layer test cases their structure, and MITRE ATLAS supplies the adversary tactics and techniques we emulate against machine learning systems. Both are living references, and our test library moves with them.
A model is one component in a larger application, so the surface around it is held to the same standards as any other assessment: OWASP WSTG and ASVS for the web tier, and the OWASP API Security Top 10 for the endpoints your model and its tools sit behind.
Evidence in this discipline looks different from a conventional test. Findings are backed by complete conversation transcripts and the exact payloads used, because a vulnerability you cannot replay is a vulnerability you cannot fix. Where model behavior is probabilistic, we demonstrate reliability rather than reporting a single lucky result.
The report serves two audiences at once: leadership deciding what risk to accept and engineers deciding what to change. Both work from the same document.
Direct injection is an attacker typing hostile instructions into your interface. Indirect injection is those instructions arriving through content the model reads on a user's behalf: a web page an agent visits, a document in the retrieval index, an email, a calendar invite, a support ticket. It matters because the attacker needs no account and no access; they only need to place content somewhere your system will eventually read. Any deployment that combines untrusted content with sensitive data or tool access is exposed to it.
Yes, and tool and function call abuse is a core focus of the engagement rather than an add-on. We map every capability the agent holds, then test what injected or manipulated instructions can do with each one: which functions can be reached, with what arguments, whether the agent's effective permissions exceed those of the user driving it, and whether actions can be chained across connected systems into something no single tool was meant to allow.
End to end. We examine who can write into the corpus and what sanitization applies at ingestion, whether the vector store enforces tenant isolation and metadata filters under adversarial queries, whether crafted content can dominate retrieval for targeted questions, and whether retrieved passages are treated as instructions rather than reference material at generation time.
We do. The model is one component, and some of the highest impact findings in these engagements are classic application flaws that model output can reach: an XSS payload the model was persuaded to generate, an SSRF through a URL the application fetches on the model's behalf, missing authorization on the endpoints a tool calls. The surrounding web and API surface is tested against OWASP WSTG, ASVS, and the API Security Top 10 as part of the engagement.
Safety evaluations ask whether a model can be made to produce harmful content in the abstract. We ask what an attacker can do to your systems and your data through the model: exfiltrate records, invoke tools, reach internal services, or drain your inference budget. Content risks are covered where they create real liability for your product, but the center of gravity is security impact you can rate, prioritize, and fix. If you want adversary emulation against your organization as a whole, that is our red teaming service.
Describe the feature, the model behind it, and the tools it can reach. We will return a proposed scope, an engagement model, and a timeline within a few business days.