Cities use AI in traffic management to time signals adaptively, detect incidents from cameras, estimate queues from connected-vehicle messages and advise routing. These systems take untrusted inputs from the street and turn them into physical outcomes, which makes them a security problem as much as an optimisation one. A wrong recommendation from a chatbot is a bad answer; a wrong signal plan is a queue that backs up through three intersections, or an ambulance stuck behind it.
This article looks at those systems from the defender's side: the data flow, the attacks that have been demonstrated on connected-vehicle signal control, input validation with code, bounding the influence of any single source, safety interlocks that sit outside the AI, privacy of vehicle trajectories and equity of who absorbs the delay. It ends with a checklist for an agency or vendor deploying such a system.
How AI signal control is wired
A typical adaptive deployment has four input types. Inductive loops and radar give counts and occupancy per lane. Cameras with vision models detect vehicles, pedestrians and incidents. Connected vehicles broadcast Basic Safety Messages, defined in SAE J2735, with position, speed and heading, received by a roadside unit at the intersection. Probe and app data give travel times on longer segments. A fusion step estimates queues and arrivals, an optimiser chooses phase order and durations, and a field controller drives the signal heads.
Two components in the diagram are not AI and must stay that way. The conflict monitor, called a malfunction management unit in NEMA cabinets, is independent hardware that watches the signal outputs and forces the intersection into flashing if it ever sees conflicting greens. The fallback plan is a fixed-time or conventionally actuated timing the controller can revert to. Together they turn the worst case of an attack from crashes into delay, which is why the security goal can be stated as bounded degradation rather than perfect correctness.
The threat model
| Threat | Entry point | Effect |
|---|---|---|
| Trajectory spoofing | connected-vehicle messages | phantom queues pull green time |
| Adversarial patches or occlusion | camera models | missed or invented detections |
| Sensor faults | stuck loops, dirty lenses | same as an attack, without intent |
| Controller or network compromise | field cabinet, central system | direct timing control |
| Training data poisoning | learned optimiser | biased or exploitable policy |
| Trajectory leakage | raw message and camera logs | tracking of individuals |
The connected-vehicle path deserves most attention because it is new and the trust assumptions are easy to get wrong. In the US, BSMs are signed under IEEE 1609.2 with short-lived pseudonym certificates issued by a Security Credential Management System. A valid signature shows that the message came from an enrolled device. It does not show that the content is true. A compromised or malicious enrolled device, including one built by an attacker with a legitimately enrolled unit, can sign any position and speed it likes. Content validation is the application's job.
Emergency-vehicle preemption is a second input that forces phases directly, whether it arrives by optical emitter, radio or a GPS-based system. Unauthorised emitters are a long-standing abuse, so log every preemption call with its source, alert on unusual frequency per approach, and make sure the AI optimiser cannot be steered into issuing preemptions itself.
Case study: one spoofed vehicle
The clearest public demonstration is a 2018 NDSS paper from the University of Michigan by Chen, Yin, Feng, Mao and Liu, which studied I-SIG, a connected-vehicle signal control system sponsored by the US Department of Transportation. In simulation of a real intersection, spoofed trajectory data from a single attack vehicle increased total delay by as much as 68.1 percent, which made traffic 23.4 percent worse than not using the intelligent system at all. The attacks exploited the planning algorithm and the way it estimated vehicles that do not broadcast when few vehicles are equipped, not a cryptographic weakness.
Three lessons generalise to any AI controller. First, one source can dominate the optimiser if nothing limits its influence. Second, the period when few vehicles are equipped is the most dangerous, because the system extrapolates from very little data. Third, the attack target was mobility, not safety, precisely because the safety interlock held. Design for the same split.
Validating inputs before the optimiser
Validate every message against physics, the map and other sensors before it reaches the optimiser. The checks are cheap and each one removes a class of cheap spoofing.
from dataclasses import dataclass
MAX_ACCEL = 4.0 # m/s^2, generous for passenger vehicles
MAX_SPEED = 45.0 # m/s on this corridor, well above the limit
@dataclass
class Msg:
pseudonym: str
t: float # seconds
lane: str | None # map-matched lane, None if off-road
s: float # metres from stop bar along the lane
v: float # reported speed, m/s
def plausible(msg, last, loop_occupied):
"""Return a list of reasons to reject; empty means accept."""
bad = []
if msg.lane is None:
bad.append("off map")
if not 0 <= msg.v <= MAX_SPEED:
bad.append("speed out of range")
if last is not None and last.lane == msg.lane:
dt = msg.t - last.t
if dt <= 0:
bad.append("replayed or reordered")
else:
implied_v = abs(last.s - msg.s) / dt
if abs(implied_v - msg.v) > 5.0:
bad.append("position and speed disagree")
if abs(msg.v - last.v) / dt > MAX_ACCEL:
bad.append("impossible acceleration")
if msg.lane is not None and msg.v < 1.0 and msg.s < 30 and not loop_occupied(msg.lane):
bad.append("claims to queue over an empty stop-bar loop")
return badThe last check is the important one: cross-validation against an independent sensor. A vehicle claiming to sit stopped over the stop-bar detector while that detector reads empty is lying or broken. Rejections should be counted per pseudonym and per roadside unit and reported to the misbehaviour process rather than silently dropped, because a sudden rise in rejections is itself a signal. Pseudonyms rotate by design, so do not expect per-vehicle reputation to last long; rely on per-message checks and aggregate caps.
Bounding influence: a worked example
Validation catches clumsy spoofing. A careful attacker sends plausible messages, so the optimiser must also limit how much any one source can move the plan. Three controls do most of the work. Cap the contribution of any single vehicle to an approach's estimated demand, for example at one vehicle's worth of queue, which sounds obvious but is exactly what extrapolation for unequipped vehicles breaks. Fuse sources with robust statistics: take the median of loop-based, camera-based and connected-vehicle queue estimates rather than trusting whichever is largest. Bound the plan itself: minimum and maximum green per phase, maximum cycle length and a limit on how far one cycle's timing can move from the last.
Worked example: an approach where the loop detector implies a queue of 6 vehicles and the camera counts 7. One spoofed vehicle reports itself stopped at the back of a long queue, and the unequipped-vehicle estimator, seeing a low penetration rate, infers 25 vehicles in front of it. Unbounded, the optimiser gives that approach a long green while real queues elsewhere grow. With fusion by median of 6, 7 and 25, the estimate is 7; with a per-cycle change limit of 10 percent of the cycle, even an attack that beats fusion only shifts a few seconds per cycle, slowly enough for monitoring to notice.
Monitoring, fallback and learned controllers
Monitoring closes the loop. Track per approach the disagreement between independent estimates, per-cycle plan changes, rejection counts per roadside unit and measured delay from probe travel times. Apply change detection such as CUSUM to these series, as described in AI risk monitoring, and define automatic actions: if disagreement on an approach stays high for several cycles, drop the connected-vehicle input for that approach and run on detectors; if delay rises past a threshold, revert the intersection to its fallback plan and page an operator.
def cusum(values, target, slack, threshold):
"""One-sided CUSUM: yields the index where a sustained upward shift is detected."""
s = 0.0
for i, x in enumerate(values):
s = max(0.0, s + (x - target - slack))
if s > threshold:
yield i
s = 0.0
# x = |CV queue estimate - loop queue estimate| per cycle on one approach
for cycle in cusum(disagreement, target=1.0, slack=0.5, threshold=8.0):
use_detectors_only(approach, from_cycle=cycle)Tune target and slack from a few weeks of normal operation on each approach, because honest disagreement varies with detector placement and equipped-vehicle share.
For learned optimisers, such as reinforcement-learning signal controllers, add model governance: train in simulation calibrated to field counts, evaluate against adversarial and faulty-sensor scenarios before deployment, ship policies through staged rollout one corridor at a time, and keep the conventional plan one switch away. Treat field cabinets and the central system as operational technology: segmented networks, no default credentials and signed firmware updates.
Privacy of vehicle data
Signal control needs counts, queues and arrival times, not identities, but raw message logs and camera footage contain trajectories. Location traces are highly identifying: de Montjoye and colleagues showed in 2013 that four spatio-temporal points were enough to uniquely identify 95 percent of people in a large mobile phone dataset. Pseudonym rotation helps on the air but not if the back end stitches pseudonyms back together.
- Aggregate at the edge: the roadside unit or controller reduces messages to per-lane counts and queue estimates, and raw messages are kept only in a short rolling buffer for debugging.
- Do not run plate readers or face detection for signal control; detection of a vehicle class is enough.
- If you publish counts or travel times, add noise with a tracked privacy budget.
- Write retention periods down and enforce them in code, with deletion logs.
Equity: who absorbs the delay
An optimiser that minimises total vehicle delay will happily give the main road long greens and make side streets, buses and pedestrians wait, because they are fewer vehicles. That is a policy choice hidden in an objective function. Measure delay per approach, per mode and per neighbourhood, report person-delay rather than vehicle-delay where bus occupancy is known, and set maximum waits for pedestrian phases as hard constraints. Compare before and after per group, with uncertainty, the same way you would audit any model with the per-group methods in AI fairness. If one area's delay rises while the city average falls, that is a finding to publish, not to average away.
Failure modes
- Signature equals truth. Accepting signed messages without content checks.
- Unbounded extrapolation. Inferring many unequipped vehicles from one equipped one.
- No independent sensor. If connected-vehicle data is the only input, nothing can contradict it.
- Silent fallback failure. The fallback plan was never tested and is out of date.
- Learned policy outside its training range. Events, road works or detector faults the simulator never modelled.
- Log hoarding. Raw trajectories kept for years for possible future analysis.
- Average-only reporting. City-wide delay improves while one area gets worse.
Trade-offs
Every check that rejects spoofed data also rejects some honest data, especially from cheap or badly calibrated equipment, which slightly reduces the benefit of connected vehicles. Influence caps and change limits slow down response to real sudden demand, such as a stadium emptying. Edge aggregation protects privacy but removes data that engineers would like for later studies. Hard pedestrian and side-street limits cost some throughput on main roads. These are the right trades for public infrastructure: a few percent of peak efficiency is a cheap price for bounded worst cases, privacy and fair outcomes, but make them explicitly and publish them.
What to do next
- Draw your data flow and mark which inputs are independent of each other.
- Confirm the conflict monitor and a tested fallback plan exist at every AI-controlled intersection.
- Add physics, map and cross-sensor plausibility checks before the optimiser, with rejection metrics.
- Cap per-source influence, fuse by robust statistics and bound per-cycle plan changes.
- Monitor disagreement and delay with change detection, and automate fallback.
- Aggregate at the edge and set retention limits for raw messages and video.
- Report delay per approach, mode and neighbourhood before and after deployment.
- Red-team the system in simulation with spoofed vehicles and faulty sensors before each release.