IOActive / Services / AI/ML Security Services

AI/ML Security Services

AI is inside the products, workflows and devices your business runs on. We test how an attacker would manipulate your models, corrupt the data behind them and abuse the systems that act on their output. We test like an attacker and report like an engineer.

Attackers do not need shell access to do damage. A prompt injection can turn a chatbot into an exfiltration channel. Poisoned data can steer a model's decisions without tripping an alarm. Retrieval-augmented generation (RAG) and tool calling, whether through function calling, plugins or Model Context Protocol (MCP) servers, turn one request into calls against files, APIs and production systems.

IOActive tests the whole AI system: the model, the data behind it, the applications and devices that call it, and the infrastructure that holds its weights. Every engagement ends the same way: findings demonstrated with evidence you can replay, fixes assigned to a named owner, and a retest once you have fixed them.

The engagements below follow the life of an AI system. Start wherever you are.

Talk to an AI security consultant

Before you build: foundations

The decisions made here shape the attacks a system will have to withstand.

AI security program and governance assessment

Does your organization know what AI it runs, who owns it, and what happens when it misbehaves? We inventory the AI in use and assess the policies and controls around it, from acceptable use and model-risk classification to vendor assessment and incident response. Findings are organized against the NIST AI Risk Management Framework and its Generative AI Profile, and anything that touches regulation, including the EU AI Act, is flagged for your legal review with the technical context attached.

Threat modeling for AI systems

Where can this system be attacked, and what would the attacker gain? We trace the paths an attacker would take through your models, prompts, agents, plugins and suppliers, and tie each one to business impact. Exposures are aligned to MITRE ATLAS, so the guardrails and detections that follow are concrete engineering tasks.

AI development lifecycle review

How do models, data, prompts and tools get built, tested and admitted into production, and where is that process open to abuse? We review it end to end and leave you with practical guardrails for data collection, labeling and CI/CD that fit how your teams already work.

While you build: code and findings

AI changes how code is written as much as what ships. In The Security Gap in AI-Generated Code (April 2026), IOActive gave 730 real-world coding prompts to 27 AI models and coding tools. Nearly a third of the generated samples (31.6%) were fully exploitable, and no model got it right every time.

AI secure code review

Is the code that wraps the model as secure as the model? We review how your application talks to the LLM: prompt construction, output handling, authentication and authorization, RAG and vector database access, tool integrations, agent orchestration, secrets and logging. If IOActive already reviews your code, this extends the engagement you run today.

Secure coding with AI: implementation and training

How do you keep the productivity of AI-assisted development without inheriting its defects? We help you decide where a human sits relative to the loop for AI-written and AI-reviewed code (in it, on it, or over it), help you put the policies and tooling in place, and train your engineers on the failure patterns we see in real engagements and in our own research on governing AI coding assistants.

Triage and verification of AI-generated findings

Your scanners and AI agents report thousands of issues. Which ones are real? We verify them: exploitability demonstrated, duplicates and false positives cleared, severity re-rated. You get back a short backlog your engineers can act on. If you run an automated AI security platform, this is also how we check what it tells you.

Before you ship: adversarial testing

Five engagements, each aimed at one part of the system. Pick the one closest to your risk; most programs add the others as the system gains autonomy.

AI model assessment

Can we trust this model to behave safely in the situations that matter to our business? We test the model's behavior, not its plumbing: unsafe or biased output, hallucination, sensitive-data leakage, instruction following and refusals, and how it behaves outside its intended use. Then we turn hostile: obfuscated and encoded instructions, unexpected languages, long-context and multi-turn attacks, and documents or images that carry instructions of their own. Vision, speech and decision systems get the same treatment. Deliverable: an AI safety assessment report, a risk scorecard and a remediation roadmap.

AI application security assessment

Can an attacker use the AI feature to reach data or actions they are not authorized for? The path from a user to your enterprise systems runs through the application, the prompt, the model, RAG, a vector database, and the tools and APIs the model can call, whatever the integration. We test each hop, including data segregation between tenants, tool permissions and third-party AI integrations, and we include the classic web, mobile and API flaws that AI features amplify. AI on devices and embedded targets is in scope.

AI agent security assessment

An agent can act, not just answer. What happens if we convince it to do something it should not? We try: read a confidential file, send an email, change a record or a configuration, run code, make a purchase, create another agent, escalate its own privileges. Every action the agent can take, and every tool it can reach, is a test case, including manipulation by another agent or a poisoned tool response. For each success we show you which control failed and recommend the fix there.

AI data and privacy assessment

Could an attacker change what the model learns or retrieves, and can the model be made to expose what it should never say? On the way in, we examine every place data enters: training and fine-tuning sets, RAG documents, embeddings and vector databases, third-party datasets and the model supply chain, looking for poisoning opportunities and gaps in provenance. On the way out, we test for accidental leakage and adversarial extraction of personal data, customer records, source code, credentials, internal documents and confidential prompts, including whether an attacker can tell that a record was used in training.

AI red teaming

Instead of attacking a network, the team attacks the AI and everything it can reach. An objective-driven campaign covers prompt injection, jailbreaking, system-prompt extraction, excessive agency, tool abuse, data exfiltration and agent-to-agent manipulation. Your guardrails are part of the target: we document each control (filters, moderation, approval workflows, rate limits, permissions) and then try to get past it, and every bypass comes with the steps to reproduce it. AI-targeted penetration tests and agentic attack simulations run under the same rules of engagement as our red and purple team services.

After you ship: operate and retest

Models, prompts, tools and retrieval sources change weekly. A finding fixed in March can come back in April through a model update nobody tested.

AI infrastructure and model custody assessment

How are your model weights stored, signed, moved and deployed, and who can reach them? We test deployment integrity, access boundaries around weights, resource limits and denial-of-service controls, observability for anomalous use, and isolation between projects and tenants, and we call out the gaps that enable model theft, manipulation or lateral movement.

Retest and regression harness

Every engagement includes replay scripts, structured logs and explicit pass/fail criteria, so your team can reproduce each finding and test the fix. After you fix, we run the same harness again to measure the change in attack success.

Continuous AI assessment

For systems that change faster than an annual test can follow, we re-run the harness on an agreed cadence and after material changes (a new model version, a new tool, a new data source), inside and outside your perimeter, and report what moved. AIUC-1, the certification standard for AI agents, requires expert third-party testing of adversarial robustness and tool calls at least every three months; a quarterly cadence here produces that evidence for your auditor. We evaluate and hand over; your team operates the controls in between.

How we work

We demonstrate exploitability rather than list possibilities, verify results across seeds and decoding settings to separate durable failures from noise, and write every issue up with the inputs and replay steps that reproduce it. Findings map to the OWASP Top 10 for LLM Applications, the OWASP Machine Learning Security Top Ten, MITRE ATLAS, the NIST AI Risk Management Framework and, for AI agents, the AIUC-1 requirements, and are flagged for legal review where they touch policy or regulation. After fixes we repeat the tests, so the result is a measured change in attack success, not an assertion.

Backed by research

The people who run these assessments publish what they find. In 2026 IOActive released The Security Gap in AI-Generated Code, the study behind the numbers above, presented Husn Canaries, its research on governing how AI coding assistants use source code, at the CSA AI Summit 2026, and contributed to Cybersecurity AI: Hacking Consumer Robots in the AI Era, published with Alias Robotics in March 2026. At CanSecWest 2025 an IOActive consultant showed how AI-generated voice clones were used in a real red team engagement. That research is where our test cases come from.

Frequently asked questions

What is the difference between a model, an application and an agent assessment?

A model assessment tests how the model behaves. An application assessment tests everything around it: prompts, retrieval, tools, APIs and permissions. An agent assessment tests what the system can do, every action and every permission behind it. Pick by the part of the system you own.

Do you need our model weights or source code?

It depends on the scope. Interface testing runs against the endpoints an attacker would see. Code review needs source access. Memorization and custody analysis need access to models or weights. We agree the level of access before we start, and the report says what each level did and did not let us test.

Which frameworks do you map findings to?

The OWASP Top 10 for LLM Applications, the OWASP Machine Learning Security Top Ten, MITRE ATLAS, the NIST AI Risk Management Framework with its Generative AI Profile and, for AI agents, AIUC-1.

Will this make us compliant with the EU AI Act, ISO/IEC 42001 or AIUC-1?

No assessment can, and we do not issue certificates. We deliver the technical evidence those programs need, controls tested rather than attested, and flag findings that touch the EU AI Act for your legal review. Governance findings can be organized against the ISO/IEC 42001 clauses you are working to. For AIUC-1, the certification standard for AI agents, our model, agent and red team assessments produce the third-party testing evidence its security, safety and reliability sections require, on the quarterly cadence they specify, for your accredited auditor to review.

What do we get at the end?

A report in which every finding is demonstrated and prioritized; the replay scripts and logs that reproduce it; fixes assigned to the model, pipeline or application layer; and a retest once you have fixed them. Model assessments add a risk scorecard and a remediation roadmap.

Can you test a third-party or SaaS AI product we use?

Yes, within the terms your vendor allows. We test the product as deployed for you: your data, your integrations, your permissions and the workflows it can reach. Where the vendor's terms restrict testing, we assess your side of the boundary and the controls you own.

Do you test in production?

Only under rules of engagement agreed in advance. Attacks that could trigger real actions run against production-like environments or with the actions stubbed, and we tell you before each test what could happen if it succeeds.

Is this instead of a penetration test, or as well as one?

As well as. AI features amplify classic web, mobile and API flaws, and an AI assessment reports the ones it finds, but a full-stack assessment of the surrounding system is still the baseline. If you already run penetration tests with IOActive, AI assessments plug into the same program and reporting.

How is an engagement sized?

A focused assessment of one model, application or agent is a bounded engagement; program and governance work is scoped to your AI inventory. Bring to the scoping call what the system does, what actions it can take, what data it can reach, how it is deployed and what access you can give us. We come back with a fixed scope and timeline.

Which system should we attack first?

Request an assessment