Kieran Fraser
WICKLOW / IRELAND
CASE STUDY 02

Breaking AI, usefully

Building tools to expose where AI systems fail — and using that evidence to make them safer, more private and more dependable.

IBM RESEARCHTRUSTWORTHY & SECURE AI2022–26
Kieran and two IBM Research colleagues at the ARES booth, with a red-teaming diagram on screen behind them
conference booth
energy
The ARES boothLive red-teaming demo

Context

At IBM Research I worked across adversarial machine learning, AI security, privacy-preserving AI and methods for evaluating the reliability of generative-AI systems. Rather than a long list of repositories, the work holds together as one theme: building tools to expose where AI systems fail, and using that evidence to make them safer.

HEART

I contributed to HEART, IBM's open-source toolkit for evaluating the adversarial robustness of AI systems, including computer vision and object detection — 104 commits according to the public contributor record.

In May 2025 I represented IBM at the first IEEE International Conference on Engineering Reliable Autonomous Systems (ERAS), at Worcester Polytechnic Institute, introducing HEART and showing how systematic adversarial evaluation can expose weaknesses that conventional accuracy testing overlooks — the gap between "this model scores well on our test set" and "this model keeps behaving sensibly when someone is actively trying to break it."

How can teams evaluate whether an AI system remains dependable when its inputs are deliberately manipulated?

Adversarial Robustness Toolbox (ART)

I contributed practical YOLOv3 and YOLOv5 examples to IBM's Adversarial Robustness Toolbox, showing how object-detection systems can be evaluated under Projected Gradient Descent attacks and adversarial-patch attacks — loading a real detector, attacking it, and inspecting how its predictions change.

ARES

I contributed to ARES, IBM's AI Robustness Evaluation System — an extensible framework for automated red-teaming of large language models, orchestrating model targets, attack goals, red-team strategies, guardrails and reporting. My part covered connector architecture, guarded model configurations, Garak integration, human-jailbreak testing, red-team dashboards and system-prompt handling.

The ARES booth at a conference, showing the IBM and Red Hat branding and a red-teaming demo on screen

The ARES booth, conference floor

Guardrails & red-teaming research

Alongside the tools themselves, I've co-authored a run of papers on LLM red-teaming and guardrails: Granite Guardian, IBM's safeguarding models for detecting harmful content and risk; MoJE, a lightweight classifier for catching jailbreak attempts; MAD-MAX, a mixture of attack strategies for automated red-teaming; a benchmark of guardrails against prompt-injection attacks; and Attack Atlas, a practitioner's field guide to the challenges and pitfalls of red-teaming GenAI systems. A separate thread looked at bias propagation in LLM-generated synthetic tabular data and AI-driven workload management for Meta OS.

AI4Media

Through the European AI4Media programme, I worked on adversarial robustness in media-integrity systems — presenting an attack-and-defence analysis of deepfake detectors at AI4Media's poster and demonstration sessions at the University of Florence, on behalf of IBM. Deepfake detection is often framed as a straightforward classification problem; in practice, the detector is itself part of an adversarial environment.

What I learned

What I value most about this kind of research engineering isn't proposing a method — it's making it understandable, testable and useful to other people. Treating red-teaming and adversarial evaluation as engineering systems, not one-off demonstrations, is what carried through HEART, ART and ARES alike. The open question I keep coming back to: how to make adversarial evaluation a default step in a system's engineering, not a specialist add-on reached for after something has already gone wrong.

Evidence