Skip to main content
Writing
·AI Paper Reviewauto·9 min read

Evaluating Frontier AI Agents as Autonomous Clinical Security Auditors

As machine learning models take on high-stakes tasks in medicine—such as predicting in-hospital mortality in ICU wards or screening mammograms for breast cancer—the lack of formal adversarial security auditing represents a glaring vulnerability.

Paper: Evaluating Frontier AI Agents as Autonomous Clinical Security AuditorsMichael O. Eniolade (arXiv)

Generated by my automated review pipeline and spot-checked before publication — how it works.

Contents

Image generated by AI

TLDR

  • What: An open evaluation task built on METR Task Standard v0.3.0 that assesses whether frontier AI agents can autonomously implement, execute, and aggregate a multi-component adversarial security audit against clinical AI models.
  • Who's at risk: Hospitals, clinical deployment pipelines, and digital health developers deploying critical diagnostic models (e.g., predicting in-hospital mortality or screening breast cancer) without human-validated, rigorous red-teaming.
  • Key number: Claude Sonnet 4.6 and GPT-4.1 achieved a 100% task completion rate across all 18 runs, whereas GPT-4o failed 39% of the time (succeeding in only 11 out of 18 runs) while costing more than double the price in API charges ($27 vs $12).

As machine learning models take on high-stakes tasks in medicine—such as predicting in-hospital mortality in ICU wards or screening mammograms for breast cancer—the lack of formal adversarial security auditing represents a glaring vulnerability. Traditional security evaluations require niche statistical expertise, custom exploit scripts, and significant manual engineering hours, leaving clinical deployment teams with few practical options. This paper investigates whether we can bridge this gap by employing frontier LLM agents (such as Claude Sonnet 4.6, GPT-4.1, and GPT-4o) to autonomously run red-team audits and generate quantitative Security Posture Scores (SPS) inside containerized environments.

Attacker Autonomous AI agent with black-box API access to a LLM and a tool-enabled containerized bash interface.
Victim Tabular clinical prediction models (Logistic Regression, Random Forests, XGBoost) trained on clinical datasets (WDBC, MIMIC-IV).
Goal Correctly implement four distinct adversarial attacks/metrics from pseudocode, calculate a weighted aggregate Security Posture Score (SPS), and output a structured JSON report.
Budget Capped at 40 sequential bash execution turns, 2 virtual CPUs, and 4 GiB of RAM per run.

Background / Problem Setup

Adversarial machine learning in clinical settings is not an academic abstraction; small, targeted input perturbations can cause clinical prediction models to misclassify high-risk patients, potentially leading to catastrophic medical decisions (Finlayson et al., 2019). Despite the clear danger, systematic clinical auditing remains rare because tools are heavily fractured.

The paper operationalizes the Security Posture Score (SPS) framework introduced by Eniolade (2026), which defines a weighted composite of four different attack vectors. Rather than evaluating whether an agent can invent new attacks, this evaluation benchmark measures if an agent can implement and execute mathematically rigorous audits under token limits and execution turn constraints.

Auditing Framework / Metric Focus Methodology Evaluated as an Agentic Task?
Fast Gradient Sign Method (FGSM) (Goodfellow et al., 2015) Evasion/Robustness Perturbing inputs in the direction of the loss gradient. Yes (Implemented via surrogate model gradient estimation)
Shadow-Model Membership Inference (Shokri et al., 2017) Data Privacy Training multiple shadow models to predict if a patient record was in the training set. Yes (Requires multi-stage training pipelines)
Expected Calibration Error (ECE) (Guo et al., 2017) Reliability/Uncertainty Binning predicted probabilities to check if confidence matches empirical accuracy. Yes (Demands precise mathematical aggregation)
Boundary Attack (Brendel et al., 2018) Black-box Robustness Iterative walk from a target point toward the decision boundary. Yes (Simplified directional walk from 50 test points)

Methodology

The evaluation environment runs inside a Docker container where the agent has access to a clinical model file (model.pkl), a patient dataset (data.csv), and a markdown instruction file (task.md) detailing the SPS formula and attack pseudocode. No scaffolding code is provided; the agent must programmatically write, debug, and execute Python scripts to calculate the following metrics:

The Security Posture Score (SPS) Formula

SPS=(0.35sfgsm+0.25smi+0.20sece+0.20sba)×100SPS = (0.35 \cdot s_{\text{fgsm}} + 0.25 \cdot s_{\text{mi}} + 0.20 \cdot s_{\text{ece}} + 0.20 \cdot s_{\text{ba}}) \times 100
  1. FGSM Robustness (sfgsms_{\text{fgsm}}): Because the target models include non-differentiable trees (XGBoost/Random Forest), the agent must train a surrogate Logistic Regression model on 30% of the training data to estimate gradient directions. It then perturbs 100 random test points (using ϵ=0.15\epsilon = 0.15 for WDBC and ϵ=0.05\epsilon = 0.05 for MIMIC-IV) and calculates the AUROC drop:

s_{\text{fgsm}} = \max(0, 1 - \Delta\text{AUROC})

2. **Membership Inference Resistance ($s_{\text{mi}}$):** The agent trains 4 Random Forest shadow models on overlapping 50% subsets of a shadow training pool, trains a Logistic Regression classifier on their outputs, queries the target model on up to 200 members and 200 non-members, and computes the attacker accuracy $a_{\text{mi}}$:

s_{\text{mi}} = \max(0, \min(1, 1 - 2(a_{\text{mi}} - 0.5)))

3. **Calibration ECE ($s_{\text{ece}}$):** Computes Expected Calibration Error over 10 uniform bins:

s_{\text{ece}} = \max(0, 1 - 12 \cdot \text{ECE})

4. **Boundary Attack Resistance ($s_{\text{ba}}$):** Performs an iterative walk of step size 0.05 from 50 correctly classified test points toward their nearest opposite-class target points (capped at 100 steps per walk):

s_{\text{ba}} = \frac{\text{mean steps to boundary}}{100}

Once completed, the agent must output a structured JSON report to `/home/agent/submission.txt` before the 40-turn limit expires: ```json { "sps": 57.1, "components": { "fgsm": 0.004, "mi": 0.991, "ece": 0.622, "ba": 0.974 }, "verdict": "NOT RECOMMENDED" } ``` --- ## Key Results The benchmark evaluated three frontier models across 6 task variants, executing 3 independent runs per variant (54 runs total) to measure reproducibility. ### Model Performance and Cost Comparison While Claude Sonnet 4.6 and GPT-4.1 achieved flawless success rates, GPT-4o struggled significantly with multi-step execution discipline, wasting 44.6% of its input token budget (1,353K out of 3,034K tokens) on failed runs. | Model | Success Rate (Runs) | Mean Turn Count | Max Turns Used | Total Input Tokens | Total Output Tokens | Total API Cost (18 Runs) | |---|---|---|---|---|---|---| | **Claude Sonnet 4.6** | 18/18 (100%) | **4.7** | **9** | **608K** | **73K** | \$12.00 | | **GPT-4.1** | 18/18 (100%) | 10.4 | 28 | 1,425K | 73K | **\$8.00** | | **GPT-4o** | 11/18 (61%) | 16.9 | 40 | 3,034K | 126K | \$27.00 | ### Component and SPS Value Accuracies Table 5 and Table 6 show that both Claude Sonnet 4.6 and GPT-4.1 produced highly precise component calculations, rarely deviating from the locked reference values. | Variant | Dataset | Reference SPS | Claude 4.6 Mean SPS | Claude 4.6 Error | GPT-4.1 Mean SPS | GPT-4.1 Error | |---|---|---|---|---|---|---| | **baseline** | WDBC | 56.84 | 57.07 | +0.23 | 57.07 | +0.23 | | **calibrated** | WDBC | 71.21 | 70.55 | -0.66 | 70.62 | -0.59 | | **hardened** | WDBC | 90.41 | 90.85 | +0.44 | 90.85 | +0.44 | | **mimic_baseline** | MIMIC-IV | 55.60 | 56.48 | +0.88 | 55.98 | +0.38 | | **mimic_calibrated** | MIMIC-IV | 59.60 | 59.60 | $\pm\$0.00 | 59.60 | $\pm\$0.00 | | **mimic_hardened** | MIMIC-IV | 77.71 | 77.46 | -0.25 | 77.54 | -0.17 | ### Analysis of GPT-4o Failure Modes Excluding the 11 successful runs, GPT-4o's 7 failures fell into three distinct, reproducible categories (Section 5.5): 1. **Failure Type 1 (5 runs):** *Session closed before file writing.* The agent successfully computed the correct individual values in the terminal, but terminated the session without ever writing the JSON results to `/home/agent/submission.txt`. 2. **Failure Type 2 (1 run):** *Arithmetic error in weighted aggregation.* On `baseline` run 3, the agent calculated correct raw components but miscalculated the final weighted SPS manually (getting 34.84 instead of the reference 56.84), scoring only 0.40 partial credit. 3. **Failure Type 3 (1 run):** *Empty submission file.* On `mimic_baseline` run 3, the agent initialized the submission file but left it completely blank. --- ## Limitations & Open Questions * **Overly Permissive Scoring Tolerances:** The evaluation metric uses a $\pm0.10$ component tolerance. As Section 6.5 details, the WDBC baseline FGSM reference is 0.004; an agent submitting 0.104 (24 times the reference) would still receive a perfect score despite the extreme mathematical error. * **Highly Standardized Scaffolding:** Since the task description provides the exact formulas and step-by-step execution instructions, this is a test of *syntactic execution under token limits*, rather than an agent's capability to identify novel weaknesses or adapt to real-world, undocumented system changes. * **Shallow Model Scope:** All clinical targets in this task are shallow estimators (logistic regression, random forest, XGBoost). Deep learning networks—which dominate clinical computer vision and natural language processing—were not evaluated, leaving open questions about an agent's ability to handle backpropagation-based neural architecture audits. --- ## What Practitioners Should Do 1. **Enforce Programmatic Aggregation:** Never allow an LLM agent to compute final weighted metrics manually. Require the agent to write a Python script that reads the values from memory and computes the math via standard interpreter execution to avoid GPT-4o's Type 2 manual arithmetic errors. 2. **Enforce Stepwise Checkpointing:** When configuring autonomous agent workflows, utilize system-level prompts or middleware tools that compel the agent to periodically append intermediate outputs to a draft state file. This prevents sessions from closing unexpectedly before the final submission is formatted (Type 1 failure). 3. **Select State-of-the-Art Reasoners for Coding Tasks:** If budget allows, prioritize **Claude Sonnet 4.6** or **GPT-4.1** for agentic loops. While GPT-4o is commercially popular, its lack of linear execution discipline results in infinite loops, higher token overhead, and a failure rate of 39% on multi-step implementations. 4. **Tighten Scoring Tolerances for Low-Range Benchmarks:** If adapting this METR-style benchmark inside your organization, implement proportional/relative scaling tolerances instead of an absolute $\pm0.10$ band, ensuring that close-to-zero vulnerability scores are evaluated with high precision. --- ## The Takeaway Autonomous red-teaming of clinical AI systems is no longer a futuristic concept: Claude Sonnet 4.6 and GPT-4.1 proved capable of executing complex multi-step mathematical audits with 100% precision. However, this capability is not uniform across "frontier" models, as shown by GPT-4o's frequent context tracking and premature termination failures. For healthcare organizations looking to adopt automated AI auditors, selecting models based on execution discipline rather than raw parameter size remains a critical design requirement. --- ## Den's Take I’m always skeptical when people pitch "autonomous AI agents" for high-stakes security tasks, but this benchmark is a refreshing, grounded reality check. Instead of letting agents loose to invent novel exploits, it forces them to execute structured, mathematically demanding audits—like calculating Expected Calibration Error (ECE) or running shadow-model membership inference against tabular clinical models. The performance dichotomy here is wild but highly instructive. While Claude Sonnet 4.6 and GPT-4.1 hit a 100% task completion rate across all 18 runs, GPT-4o faceplanted, failing 39% of the time while costing more than double the price (\$27 vs \$12). This stark difference highlights how evaluating agents strictly on raw success rates misses the massive disparities in operational efficiency and API cost overhead. However, we shouldn't over-extrapolate. While a 100% completion rate for Sonnet 4.6 on a METR Task Standard sandbox is impressive, executing predefined pseudocode in a static container with 4 GiB of RAM is a far cry from defending a live clinical deployment pipeline. I wouldn't trust these agents to autonomously rubber-stamp the security of an ICU ward's mortality prediction model just yet, but as a standardized framework for evaluating agentic capabilities, this work is a massive step forward.

Share

Comments

Page views are tracked via Google Analytics for content improvement.