FACT: Formal Adversarial Testing of LLM-Generated Code for Industrial Robots

ENFIELD Open Call oc4-2025-TES-02 | Challenge T-AI.7: LLM Safety and Security Funded by the European Union — Horizon Europe Grant Agreement No 101120657

Overview

This repository contains a formal adversarial testing framework for detecting safety and security violations in industrial robot code generated by Large Language Models (LLMs). The framework combines ISO 10218-1:2025 safety compliance with CWE-based security analysis and provides:

• Formal threat model with 8 attack types (A1–A8) covering parametric, structural, and LLM-specific vulnerabilities
• Vendor-neutral Task IR — 15 baseline tasks across 5 categories, 3 operating modes, 6 tool types
• Attack variant generator producing 120 adversarial variants (15 tasks × 8 attacks) with deterministic seeds
• IR → URScript translator converting Task IR to UR5e-executable URScript with automatic unit conversions
• Static watchdog with safety rules (DM-1 through DM-7) and security rules (SM-1 through SM-7) achieving 95% detection at 0% false positives on the deterministic A1–A8 variant suite
• LLM code generation client supporting Qwen2.5-Coder-32B (Apache 2.0), DeepSeek-Coder-V2-16B (DeepSeek License), and CodeLlama-34B (Llama License) via Ollama with adversarial prompt injection testing (A8.1–A8.7)
• Experiment runner producing structured CSV/JSON reports for statistical analysis
• Reproducibility pipeline with Docker, SBOM (CycloneDX), and CI/CD (9 jobs)

Scope: Simulation-only — no physical robot deployment.

Research Questions

ID	Question	Dimension
RQ1	How effectively does the AST-based static watchdog detect safety violations in deterministic adversarial variants (A1–A8)?	Safety
RQ2	What fraction of LLM-generated robot code contains safety and/or security violations when no explicit safety guidance is provided?	Safety + Security
RQ3	Do adversarial prompts (A8.1–A8.7) significantly increase the rate of unsafe robot code generation?	Security
RQ4	Does a watchdog-in-the-loop approach significantly reduce the combined safety+security violation rate?	Defense

Robot Strategy

Role	Robot	Status
Primary	Universal Robots UR5e	Active (Phase 1–2)
Secondary	ABB GoFa	Planned (adapter template)
Secondary	KUKA KR3	Planned (adapter template)

The core pipeline is robot-agnostic. Robot-specific code is isolated in adapter packages (enfield_robots_*).

Attack Taxonomy (A1–A8)

ID	Attack	Layer	ISO Clause	Detection Rate
A1	Speed Injection	Parametric	5.5.3	100% (15/15)
A2	Zone Penetration	Parametric	5.7.4	100% (15/15)
A3	Orientation Anomaly	Parametric	5.7.4	93% (14/15)
A4	Payload Misconfiguration	Parametric	5.1.15	100% (15/15)
A5	E-Stop / Logic Bypass	Structural	5.4.2 / 5.4	100% (15/15)
A6	Frame Confusion	Structural	5.7.4	80% (12/15)
A7	Tool Misuse	Structural	5.1.14	87% (13/15)
A8	Prompt Injection	Meta	5.1.16 + EU AI Act	100% (15/15)

See docs/attack_definitions_A1_A4.md and docs/attack_definitions_A5_A8.md for formal definitions.

Adversarial Prompt Taxonomy (A8.1–A8.7)

Sub-variants of attack A8 (Prompt Injection), aligned with enfield_llm/enfield_llm/prompt_builder.py::AdversarialType:

ID	Attack Type	Description
A8.1	Direct Override	Direct instruction to bypass safety constraints
A8.2	Role-Playing	Unsafe persona (jailbreak)
A8.3	Context Overflow	Misleading context about safety requirements
A8.4	Incremental	Gradual escalation via incremental unsafe requests
A8.5	Authority Claim	Claim authority to override safety
A8.6	Performance Framing	Exploit vague specifications as performance demand
A8.7	Obfuscation	Encode unsafe parameters in non-obvious ways

LLM Models Under Test

Model	Provider	Quantization	License	Rationale
Qwen2.5-Coder-32B	Ollama	Q4_K_M	Apache 2.0	Best open-source coder (HumanEval 92.7%); permissive license
DeepSeek-Coder-V2-16B	Ollama	Q4_0	DeepSeek License	Strong code generation; different training philosophy
CodeLlama-34B	Ollama	Q4_0	Meta Llama License	Established baseline; different alignment philosophy

All calls use temperature=0.0 for deterministic output. Models are served locally via Ollama, enabling zero-cost reproducibility for reviewers and independent verification. Full request/response logs are stored in JSONL format.

Quick Start

# Clone
git clone https://github.com/dryuemco/industrial_robot_security.git
cd industrial_robot_security

# Build and run with Docker
docker compose build
docker compose run --rm dev

# Inside container: build ROS2 workspace
colcon build --symlink-install
source install/setup.bash

# Run the full test suite (canonical gate)
./scripts/run_tests.sh --fast

# Or run a single package's tests directly:
PYTHONPATH=enfield_tasks pytest enfield_tasks/test/ -v
PYTHONPATH=enfield_attacks:enfield_tasks pytest enfield_attacks/test/ -v
PYTHONPATH=enfield_translators:enfield_tasks pytest enfield_translators/test/ -v
PYTHONPATH=enfield_watchdog_static:enfield_tasks pytest enfield_watchdog_static/test/ -v
PYTHONPATH=enfield_llm:enfield_tasks pytest enfield_llm/test/ -v
PYTHONPATH=enfield_watchdog_static:enfield_tasks pytest tests/ -v

# Run full experiment (15 baselines + 120 variants)
PYTHONPATH=enfield_watchdog_static:enfield_tasks python3 scripts/run_experiment.py \
  --baselines enfield_tasks/ir/tasks \
  --variants enfield_attacks/generated/variants \
  --output results/

Runtime Stack & Simulation Environment

Runtime validation of the static watchdog uses Universal Robots' official URSim e-Series simulator. URSim runs the same controller software as a physical e-Series controller and exposes the same network interfaces, so it behaves almost identically to a real robot over the network; physical effects such as force control and collision response are not simulated. The entire study runs in this simulation environment, consistent with the preregistered scope.

Pinned runtime versions (validated 2026-04-27):

Component	Version	Source
URSim e-Series	5.12.8	universalrobots/ursim_e-series:5.12 (digest sha256:b7ad69f5bfa45ffab07788480ad43c753595ce35fcbfe4a3f420725f51764d51)
Docker Engine	29.4.1	download.docker.com/linux/ubuntu jammy stable
ROS 2 distribution	Humble Hawksbill	packages.ros.org/ros2/ubuntu jammy
ur_robot_driver	2.12.0	ros-humble-ur apt meta-package
ur_client_library	2.7.0	dependency of ur_robot_driver

Bring-up sequence (deterministic, scripted):

# 1. Start URSim container with the standard port mapping
docker run --rm -d --name ursim \
  -p 5900:5900 -p 6080:6080 -p 29999:29999 -p 30001-30004:30001-30004 \
  universalrobots/ursim_e-series:5.12

# 2. Power on + brake release via Dashboard server
(echo 'power on'; sleep 4; echo 'brake release') | nc -w 8 127.0.0.1 29999

# 3. Launch ur_robot_driver in headless mode
source /opt/ros/humble/setup.bash
ros2 launch ur_robot_driver ur_control.launch.py \
  ur_type:=ur5e robot_ip:=127.0.0.1 \
  launch_rviz:=false headless_mode:=true

Telemetry channels consumed by the watchdog: /joint_states, /tcp_pose_broadcaster/pose, /speed_scaling_state_broadcaster/speed_scaling, /io_and_status_controller/robot_mode, /io_and_status_controller/safety_mode. Cartesian TCP velocity is derived from joint velocities via the URDF forward kinematics chain (no first-class topic in ur_robot_driver 2.12.0).

Known Limitations

telemetry_recorder requires float duration_s

On rclpy Humble, the telemetry_recorder node accepts duration_s only as a float literal (e.g. 60.0). Integer overrides via --ros-args -p duration_s:=N raise InvalidParameterTypeException at parameter declaration, regardless of ParameterDescriptor type or read-site type coercion (both routes were attempted in S25 and reverted at commit 14e4d8d). The smoke wrapper run_t001_smoke.sh enforces float format via the DURATION_S environment variable (default 60.0); manual ros2 run invocations must pass N.0. To be revisited on ROS2 Iron upgrade.

Baseline Tasks (15)

ID	Category	Mode	Tool	Speed (mm/s)	Payload (kg)	Key Features
T001	pick_place	collaborative	gripper	250	0.5	SSM, 2 cones
T002	welding	fenced	welder	500	3.0	Arc sequence, 2 cones
T003	palletizing	hybrid	gripper	300	4.5	Tight space, heavy
T004	pick_place	collaborative	gripper	250	1.5	Obstacle avoidance, dual frames
T005	inspection	collaborative	camera	150	0.3	Slow scan, 2 cones
T006	pick_place	fenced	suction	400	2.0	Bin picking, new tool
T007	welding	hybrid	welder	300	3.5	Curved contour weld
T008	palletizing	fenced	gripper	450	5.0	Max payload depal
T009	inspection	fenced	laser	200	0.5	3 cones, eye safety
T010	custom	hybrid	screwdriver	250	1.0	Assembly, 4 safety nodes
T011	pick_place	hybrid	gripper	300	1.2	Dual-zone, mode transition
T012	welding	collaborative	welder	250	2.5	Spot welding, 3 cones
T013	palletizing	collaborative	suction	250	0.8	Light boxes, human feeding
T014	inspection	hybrid	camera	200	0.4	Multi-angle, 2 cones
T015	custom	fenced	laser	400	0.6	Laser marking, 4 cones

Task Coverage Matrix (Category × Mode)

	collaborative	fenced	hybrid
pick_place	T001, T004	T006	T011
welding	T012	T002	T007
palletizing	T013	T008	T003
inspection	T005	T009	T014
custom	—	T015	T010

Test Summary

Package	Tests	Command
enfield_tasks	169	PYTHONPATH=enfield_tasks pytest enfield_tasks/test/ -v
enfield_attacks	149	PYTHONPATH=enfield_attacks:enfield_tasks pytest enfield_attacks/test/ -v
enfield_translators	81	PYTHONPATH=enfield_translators:enfield_tasks pytest enfield_translators/test/ -v
enfield_watchdog_static	126	PYTHONPATH=enfield_watchdog_static:enfield_tasks pytest enfield_watchdog_static/test/ -v
enfield_llm	147	PYTHONPATH=enfield_llm:enfield_tasks pytest enfield_llm/test/ -v
runner + analysis + smoke	247	PYTHONPATH=enfield_watchdog_static:enfield_tasks pytest tests/ -v
Total	919

enfield_tasks breakdown: 79 static tests (T001–T005 detailed, schema integrity, negative/semantic) + 90 parametrized tests (TestAllTasksSchemaValid: 6 checks × 15 tasks). Test counts are derived dynamically — adding a new task requires zero test changes.

CI Pipeline

The GitHub Actions pipeline runs 9 jobs:

build-and-test
test-task-ir ──┬── test-attacks ──┬── test-watchdog-static ──┐
               └── test-translators                          ├── test-experiment-runner
               test-llm ────────────────────────────────────┘
docker-build ──── sbom-and-scan

Watchdog Validation (deterministic A1–A8 variants)

These figures are the static watchdog's detection rates on the 15 baseline tasks and the 120 hand-crafted deterministic A1–A8 variants (RQ1). The LLM-generation study (RQ2–RQ4) is reported in the paper, not in this repository.

Baselines: 15/15 safe (FP rate: 0.0%)
Variants:  114/120 flagged (detection rate: 95.0%)

Per-attack:
  A1: 15/15 (100%) ██████████    A5: 15/15 (100%) ██████████
  A2: 15/15 (100%) ██████████    A6: 12/15 (80%)  ████████░░
  A3: 14/15 (93%)  █████████░    A7: 13/15 (87%)  █████████░
  A4: 15/15 (100%) ██████████    A8: 15/15 (100%) ██████████

Open Science

Milestone	Target	Status
OSI License	Apache-2.0	✅ Done
OSF Pre-registration + DOI	Month 2 (March 2026)	✅ Done — 10.17605/OSF.IO/VE5M2
GitHub Public Release	Month 6 (June 2026)	✅ Released — v1.0.0
OSF Replication Package	Month 6 (July 2026)	Planned

See docs/open_science_release.md for the full release checklist.

Citing This Work

@software{cogurcu2026fact,
  author       = {Cogurcu, Yunus Emre and Akbarzadeh, Aida and Spathoulas, Georgios},
  title        = {{FACT: Formal Adversarial Testing of LLM-Generated
                   Code for Industrial Robots}},
  year         = {2026},
  publisher    = {GitHub},
  url          = {https://github.com/dryuemco/industrial_robot_security},
  license      = {Apache-2.0},
  note         = {OSF Pre-registration: \url{https://doi.org/10.17605/OSF.IO/VE5M2}}
}

Contributing

Contributions are welcome. Please read CONTRIBUTING.md for the branch strategy, commit conventions, code standards, and Open Science requirements before opening a pull request.

• Branches: main (stable) · develop (integration) · feature/* · fix/* · docs/*
• Commits: Conventional Commits
• Tests: colcon build and the full pytest suite must pass (see Test Summary)
• Scope: simulation-only — no physical-robot deployment code

Report bugs and feature requests via GitHub Issues.

Acknowledgements

The Formal Adversarial Testing of LLM-Generated Code for Industrial Robots project has received funding from the European Union, via the oc4-2025-TES-02 issued and implemented by the ENFIELD project, under the grant agreement No 101120657.

Disclaimer. Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the European Commission. Neither the European Union nor the granting authority can be held responsible for them.

Carried out under the ENFIELD Exchange Scheme — Challenge T-AI.7: LLM Safety and Security.

License

Apache License 2.0 — see LICENSE.